Jump to content

Mike Torrettinni

Members
  • Content Count

    544
  • Joined

  • Last visited

  • Days Won

    1

Mike Torrettinni last won the day on July 17

Mike Torrettinni had the most liked content!

Community Reputation

52 Excellent

Technical Information

  • Delphi-Version
    Delphi 10.2 Tokyo

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Oh, no, it crashed on first refresh to show a change in repository. Shame.
  2. No, I guess I missed it. I like the checklist at the beginning and what is missing!
  3. I'm a single developer, so the stress test I put on the tool is minimal. I read a lot of bad reviews on it, but for me it works flawlessly. I do remember it looks completely different than what I saw a couple of years ago at the client's site. I use latest version, not sure what that version was.
  4. Thank you all for recommendations! I installed git and tested a few tools - with private github repositories: - TortoiseGit - first one to use, so I was still learning everything, but it was annoying to use with right-click from explorer - Fork - next one I tried, and of course I was impressed by it, compared to TortoiseGit, fast UI, easy to use - SourceTree - feels like copy of Fork, but free - GitKraken - you need to register account with them - skipping - SmartGit - doesn't have an option to recognize repository hosting, others have this option - skipping - Tower - similar to Sourcetree and Fork, but little sluggish, crammed UI For now staying with SourceTree - it's like like Fork, but free.
  5. Thank you, good approach.
  6. Thanks, I don't use it very much, yet. Good to know for the future.
  7. Ok, no worries, will try to avoid temporary coupling, as suggested.
  8. Eh, last night I decided to go with 'use fields by default, unless there is a reason for parameters'. I was happy with this, I had a plan. Now, I see different suggestions. 🙂 I only have this implemented in a class that has 100+ methods and I was testing if here is any difference between method using aClassMainData as parameter of fClassMainData field. But I kind of like class methods, for the 'perceived' tidier implementation. Good point. In this case I would definitely rethink what needs to be used. Well, this is getting a little too much, I'm not ready for Interfaces, yet. Classes first. But, isn't solution for temporal coupling just simple checking if class was initialized, if needed data is present? b := TEndpointAddressBuilder.Create; e := b.ToEndpointAddress(); function TEndpointAddressBuilder.ToEndpointAddress: string; begin Result := ''; if fURI <> '' then Result := ConvertURIToEndpointAddress; end; in this case assigning e will not fail in runtime. Right, or am I missing the point of temporal coupling?
  9. That's a good point! I assume a recursion is probably meant here. Not using many of them, but I will be careful.
  10. This question keep getting stuck in my head and I wonder which way should I do it: Does anybody have a good rule or practical advice when to use class fields directly and when to pass them as parameters, when used in class methods? For example - simple public Search method: // public method procedure TMyClass.Search(const aFieldName: string); begin fFieldName := aFieldName; // fFieldName is TMyClass field // TMyClass.SearchByFieldName SearchByFieldName; // or TMyClass.SearchByFieldName(const aFieldName: string) SearchByFieldName(fFieldName); // or SearchByFieldName(aFieldName); end; procedure TMyClass.SearchByFieldName; begin DoTheSearch1(fFieldName); DoTheSearch2(fFieldName); end; // or procedure TMyClass.SearchByFieldName(const aFieldName: string); begin DoTheSearch1(aFieldName); DoTheSearch2(aFieldName); end; I keep trying to justify one of the other approach, and a lot of times I justify passing parameters in case I need to extract method, and use it as standalone or copy to another class. In most cases this doesn't happen. I guess this is left from 'old' style where all methods were organized by units, not classes. There you need parameters. Any advice is welcome, thanks!
  11. Mike Torrettinni

    When can Class.Create fail?

    aha... exception stops the flow and next/upper try...finally/except handles it - outside the current method. OK. I do always use try.. finally, but I thought we are safeguarding the usage of class in case variable is nil, if create fails. Never questioned it, until today 🙂 Now I understand. Thanks!
  12. Mike Torrettinni

    When can Class.Create fail?

    OK, I understand, make sense. One last thing I'm still struggling with: can Create not actually create class and 'return/ or leave' variable as nil, but it also doesn't raise exception? this is probably not possible, right?
  13. I've been reading this article (and comments) https://community.idera.com/developer-tools/b/blog/posts/try-finally-blocks-for-protecting-multiple-resources-in-delphi Even thought it talks about protecting multiple classes (resources), I'm referring to single class: In most cases (or all) we wrap using Class after create with try... finally: var vMyClass: TMyClass; begin vMyClass := TMyClass.Create; try ... using vMyClass... finally vMyClass.Free; end; end; I assume that the only time creating class fails is when class constructor fails (it tries to execute some code that fails). Is that correct? If this is correct (that constructor is the only point of failure) then if there is no constructor defined in specific class - we don't need try...finally? Or are there other situations that creating class can fail?
  14. Mike Torrettinni

    Cannot copy a TCard in the Structure Panel

    I don't want to imagine anybody sick, weird and diabolic working on Delphi 🙂
×