Stefan Glienke

FWIW in Delphi that fear is often caused by the fact that new features often don't work for years and are poorly designed so they affect some important aspects negatively such as compile speed or runtime performance which often you encounter way later when you already extensively use them (latest example: inline variables). Many other languages have a plethora of incredibly smart people designing things for years with enough time to thoroughly test and ensure they are zero or minimal overhead.

You do realize that the -x options are provided by the fixpack and thus are only via some hackery done by Andreas and might not be stable, yes? @jbg FYI

I do and it will be subject of one of my talks I will be giving at some conferences in the coming months so I will not spoil that before.

IOW: no, they still don't work

Even though I don't see them pop up when browsing the forum itself (kudos to the mods being quick enough or having automated it) I see stuff like this on beginend.net almost every day recently:

Which also was an RTL thing that was very late to the party and thus has to compete with solutions that already existed before it. And yes if there have been other solutions in need of some multi-threading they either had to roll their own or only be compatible or rely on other third party components themselves which they usually rather refrain from. So what we have achieved in the past few years in the RTL is closing the gap on the feature matrix to give the impression that for nowadays standard usecases like http, json or easy parallel processing you don't need any specific third party components or libraries but once you start using them you quickly run into numerous issues that range from "little annoying" to "absolute showstopper". And often fixes either take multiple iterations or major versions and range from "now you broke something else" to "dirty hack because of keeping broken behavior because of backwards compatibility" Even using the smallest RTL feature these days causes me to look into the implementation before recommending it to my coworkers, telling them to stop using them or not giving green light to upgrade the newest Delphi version (RSP-19439 for example) - sad but true. If it weren't for licensing reasons and the impossibility to fix many bugs that interest me by just recompiling the RTL (depending on what units you change) I would have started an "enhanced RTL" project already to fix the most annoying issues (like the ridiculous code bloat caused by System.Generics.Collections/Defaults and many other annoyances). At least the latter was solved by banishing those units from our code entirely and exclusively using spring4d collections. Using any third party code and the RTL and VCL itself though still is affected by that.

We have a catch 22 here. If stuff does not work I don't use it - especially if it tries to solve a task that has already been solved years ago. So if people don't use it less people are affected by bugs and less likely it is they get fixed - however even when issues are being reported by many people it takes time to fix them and only with an upgrade you get those fixes. With a library like OTL you don't need to upgrade your entire IDE to get some bugfix. This is the fundamental flaw you have when IDE, compiler and runtime are so tightly coupled that they cannot be upgraded individually. That plus a lack of quality control.

I doubted that already

Don't tell me - but this the almighty excuse brought up by the decision makers almost every time some issue like this is brought up - "but what about existing code" - like for that dreaded "directly passing result of ctor call to interface parameter issue" - what about existing code? Well existing code is most likely suffering from a defect. The stupidity of the Delphi compiler in almost every aspect and the unwillingness to change anything significant on that is making me furious!

Updating a single application even if complex is not a hard task, almost every other major IDE out there can do it. Only Delphi developers have to manually apply hotfixes by unzipping some archive and unblock the contained binaries...

Changing that would raise some warnings in existing potentially defect code and some people don't want that Similar to being able to call non virtual class methods on instances

TL'DR 😛 Btw you can utilize the xmldoc for that - we are doing that for some of our classes and pump that into confluence. Does not need a single line of executable code or RTTI inside the to be documented to produce this. The only disadvantage this has is that implementation and what's in the xmldoc might differ.

Keep voting: https://quality.embarcadero.com/browse/RSP-13290 And given that the compiler already knows line numbers and the filepath it's working on for Assert it should be almost no effort to implement something like this as well: https://docs.microsoft.com/en-gb/dotnet/api/system.runtime.compilerservices.callermembernameattribute?view=netframework-4.7.1

Wrong approach - use a parser to generate doc out of some code. Agree on the nameof intrinsic though - but for other reasons.

That is because internally all RTTI through an TRttiContext is handled by a singleton instance and DUnitX itself is already using some TRttiContext. So the internal singleton already exists and your usage causes it to just create more objects that are then owned by that singleton instance which outlives the unit test because DUnitX keeps it alive. This general issue of cached objects created during unit tests that keep existing after the test ran and thus are considered leaks is known and LeakCheck has mechanisms for that. Add the following line into the dpr (needs LeakCheck and LeakCheck.Utils in the uses) TLeakCheck.InstanceIgnoredProc := IgnoreRttiObjects; For more details please see the Ignoring section in the LeakCheck readme In practice there are many more places in RTL and possibly custom code that use lazy creation/caching mechanism and are subject to such a leak detection approach (see InitializeLeakCheck in Spring.TestRunner.pas for some example of such madness if you are curious)

I am almost sure MMX Code Explorer can handle both - but @Uwe Raabe certainly knows better.

And they fully qualify every type -.-

We used SvCom for years but threw it away as we did not need any of those fancy features - using a simple TService with some additional code to let the service run as normal application that simply shows a small form with a start and stop button (useful for debugging)

The issue is not a memory leak but the use of an interface reference after the object behind it was destroyed already - see first post.

I read your post three times but I could not make any sense of it. What does "BPL are screwed" mean? And what does "bpl output" mean? The binary size of the bpl? So when using the class helper the binary is smaller than when not using it? What class helper? Provide more information and be less sketchy.

We keep all third party components in a separate git repository and are using Delphi Package Installer (slightly modified version) to build and install into the IDE on a new installation - also keeping all binaries in that repository (via git lfs). That enables going back and forth between versions without anything else than a branch or tag change of that repository (unless the vendor changes package structures - then it might require running the Delphi PI again) Initial installation or update is done by one developer on his machine using whatever setup or installation routine the vendor uses (I did most of the initial installation ones and try to do them with as little modifications as possible to make updating them a quick thing) and then putting them into the repository.

It handled a TList<TPoint> which I tested better than REST.Json - good. Unfortunately it's based on System.JSON which makes it a no go for me. What I like though is the architecture that enables encapsulating different collection types for serialization/deserialization - I just wished it would not require RTTI for builtin RTL collection types. From a quick look though extending serialization via own custom serializers is only possible for one specific PTypeInfo which makes this unusable for own generic types. For that the TCustomSerializer classes would need a CanHandle(AType: PTypeInfo) function or alike. This would also enable the currently hardcoded support for dataset, stream and RTL collections to be handled over this mechanism without having to hardcode them into TNeonSerializerJSON.WriteDataMember

Amazing amount of unittests

*puts sunglasses on and holds a pen up*

Yes, the need for those given that you just check for different cases on the same thing (typical if x is button then ... else if x is edit then ... else if x is ... cases) just comes from case of syntax element being of limited use only. Those horrors would not be worse than half a mile of if-then-else-if "ladders". Especially since in those you can easily hide some non conform pattern which can easily get unnoticed - for example checking x for 10 different types but then in some else if check y for something...) Language improvements of the category "syntax sugar" (i.e. something that could be done before but in a more convoluted way) should improve code readability by reducing the ceremony around the essence of what the code is supposed to do.