Stefan Glienke

The problem is that historically Delphi did not know about interfaces and many of the concepts he describes and even though Delphi now knows about interfaces the RTL/VCL and most of other basic frameworks don't use them. So most of the RTL/VCL code is still inheriting from more or less not really abstract classes in some long inheritance chains (remember those posters that came with older versions of Delphi?) - now try to teach a Delphi developer that only knows this example different...

There is a bit more to it than simply following a mantra - here is some more food for thought: https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose

I predict that any time in the future the publisher does not want to block until all subscribers have processed their events and thus you will need to do that asynchronously which requires a less naive approach to iterate the subscribers. I know from my multicast events that this can cause a major headache trying to keep performance (not locking all the time) and still being able to detach subscribers in the middle of handling a publish without running into an off by one.

That is why in my lists (inspired by the behavior of .NET) it causes an exception when the source changes during enumeration causing the enumerator to be possible invalid. I also have a Remove method where I can pass a delegate that determines what elements to remove. IME much more robust than handwriting loops and keeping track of such things.

TList<T>.GetEnumerator does not call DoGetEnumerator but directly creates its TEnumerator - so overriding it is pointless. Considering the design in TEnumerable<T>.GetEnumerator to use the virtual DoGetEnumerator I would call this a defect that TList<T> does not stick to this pattern but has its own GetEnumerator. Anyhow why make a new list class just to enumerate stuff in reverse order?

Except when the framework is very naively written and adds a lot of unnecessary overhead and indirections. And yes, unfortunately for some situations IOUtils and other RTL units do exactly that.

Not natively using [weak] attribute. You can only make a record with a [weak] IFoo field and put that into the array.

Common is to post below on forums like this and above on newsgroups where you reply via email.

Interesting - I remember playing that game - however it probably was kinda mediocre given the fact that I totally forgot about it until I saw the screenshot which reminded me.

No, it was a logical consequence of people not only thinking up to the next fiscal quarter and realizing that not rewriting the compiler would end in a dead end rather sooner than later. That combined with a company that has enough resources to put quite some people on a project for years. But we are getting dangerously close to becoming political 😉

FastMM4 FullDebug in a debug build of our application - LeakCheck in unit and integration tests If any third party leak analysis tool claims that FastMM has a memory leak it probably will tell you the call stack of where it comes from and you will be able to find it. Also are you aware that there is RegisterExpectedMemoryLeak function that the third party tool might not be aware of and has a false positive? As for Deleaker - I think that tool and me won't become friends. UI is irritating and if its burning 100% of my CPU for minutes while triggering a million werfault.exe processes that it supresses until I press cancel to find some memory allocation leaks from that simple program I can't imagine what it will do when I let it run for a real application. "Sorry, but's a no from me"

The problem is not any 3rd party MM but the fact that some pieces in the RTL are deallocated within System.pas finalization which takes place after detaching/finalizing any 3rd party MM (if that one does something in its finalization block as posted in the previous post). And then it tries to give back memory to the system that it orginally had from the already unloaded/detached 3rd party MM. There are various fixes in the RTL (I don't remember which version they did that in) that use SysGetMem/SysFreeMem to bypass the pluggable memory manager API. It can very well be the case they missed something or you are using a version that does not have them yet.

Write a visualizer for TListHelper that does not simply show all its fields the standard way but as array. Or simply call its FListObj.ToArray as evaluated expression instead (which would be the dumb version as that causes allocation every time).

Correct - it seems to be EurekaLog (see point 3. "When memory is released": https://www.eurekalog.com/help/eurekalog/index.php?memory_leaks_page.php) I would say its that a destroyed TFieldValue was not removed from the list inside the TGridSet - so locate where those are destroyed and check if they are properly removed from that list when in it.

They probably should fix this with a debugger visualizer that knows to interpret the FItems field in a TListHelper properly (it also has the fields FCount and FTypeInfo to be able to)

No point of injecting the comparer via container. Make a parameterless ctor where you create it. I suggest reading Nick hodges book on DI about the difference of "createables" and "injectables".

I meant the implementing class of the comparer or are you using the default from Generics.Defaults? Then just RegisterInstance(TEqualityComparer<whatever>.Default()); Or make an overload without parameter where you create the default comparer and mark that one with [Inject] for the container to use that one because imo a comparer if it does not have dependencies itself falls into the category of a createable thus does not need to be injected.

Is that before or after hell freezes over or easter and christmas are on the same day?

Does the implementing class itself has dependencies the container should build? Otherwise simply use RegisterInstance. RegisterType with DelegateTo currently does not work although it could let it pass without guid because it then internally does not need it. It's an interesting point though - the fact it needs a GUID is only internally because when creating class instances and resolving them as interface it uses Supports. However since Delphi XE there is some additional type info available for the classes interface table so the container could find the correct one only via the interface type info. I will put that on my list to research to relax that requirement in the future. Oh, how I wish we could use open generics in Delphi ...

Large enough that you don't want to rebuild third party code every time you hit F9+something or waste minutes on the CI server

As Jeroen already mentioned: use DelphiAST - that is based on the Castalia parser code which was based on Martin Waldenburgs code. It is used and maintained by the author of FixInsight and many others and can handle any Delphi code out there. It had a lot of fixes due to it being used in FixInsight which is widely used by numerous people. It even supports inline variables (hello Error Insight!)

I am just saying that I dislike having to actually compile the project - maybe I just did a change that causes a compile error which is why I trigger the search ("what unit was this thingy in again...?" or similar). Sure I could have produced the mapfile before I do that change and then let it search it but I have the feeling this will be very inconvenient. Coworker of mine did an IDE plugin for us to automatically propose all the paths that some units referenced in the project are in to add to the search path so I know it's possible (yes, probably a bit more work than simply parsing the map file)

That's why Peter said prebuild - you do that once (and whenever you need to fix some of 3rd party code which is compared to your own code rather rare talking from experience) and then use the produced dcus. That way you only get compiler messages from your code without being mixed with any 3rd party noise. If you work on a large enough application with enough developers that produce builds nonstop rebuilding the same unchanged source code every time is an issue. Especially when Delphi decided that it does not like the "compile" option for whatever reasons and forces you to do "build"

Funny that you bring up that DevExpress change - I remember upgrading our software and it was a non-issue. And in fact the "what's new" for that version explains exactly what to do. Not saying any of us is right or wrong but you can see that something is a huge issue for one and none for another. Yes, there is always some bad code that did not follow best practices or did not properly encapsulate something, leak an implementation detail or does something else making it a chore to move forward. But that is exactly why I wrote what I wrote 2 posts ago. You can always come up with an excuse (valid or not) to damn some breaking change. However sometimes you have to take the bitter pill to move forward painlessly either yourself or the library/framework developer that decided for such a change. I for example will introduce quite some breaking changes for the next version of Spring4D and I experienced them myself when migrating a branch of our software to an early version and experienced all the required work. I even reverted some change because I saw that it was rather painful to find all the places and convert them easily. That means as a developer of a component/library/framework you should use that yourself in more than a toy project to get a feeling what consequences possible changes have to evaluate if they should be taken or not. And it then is an important responsibility to document them and if necessary provide some tooling to migrate your code - I remember more than 10 years ago when moving from QuantumGrid 3 to 4 (I think) DevExpress provided a tool to convert all your code for that heavy breaking changes that came with that version change. If they would not have done that, I guess no existing customer would have done it - however I cannot tell about the problems that still existed, I joined the company when the change was done already.

For once I have to wholeheartedly agree with Rudy - I have to mark that on my calendar.