Dalija Prasnikar

Because TThread can be self destroying or not based on the value in FreeOnTerminate property which can be configured after construction. Besides that property, there are others that can be configured before thread starts running, Also how would you prevent developers from taking reference of any abstract class that is meant to be extended and is therefore publicly accessible?

I guess it was not anticipated that developers would store references to self destroying threads. And without having a reference you cannot wait for such thread. References to self destroying threads basically become invalid the moment the thread is started and they can only be used for initial configuration for threads that were created in suspended state. Once thread starts running, you should not touch the reference anymore. From documentation: https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread.CreateAnonymousThread https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread.FreeOnTerminate I am not going to discuss about how one can potentially use anonymous threads beyond their intended purpose: being fire and forget kind of thread, because such code can be very fragile and cause more problems than it solves. And like I mentioned earlier in this thread, without having a very specific code and a use case, it can be hard to discuss potential problems and solutions because in multithreading even slight changes in code and how it is used can make a huge difference and break it.

You don't need to post the code within Execute. We just need to know how are you creating and waiting for a thread. Is it a self destroying thread, or not. If it is self destroying thread with FreeOnTerminate set to True, then you cannot wait for it. If you need a waitable thread, just use a thread with manual memory management and free it when you are done. There is nothing wrong with creating and destroying thread when you need one. The only problem with recreation is that creating and starting a thread takes some small amount of time, and if you need to do that frequently (multiple times in a second) then such code will have some small impact on performance.

It would help if you can post the code example here. With threads even slight change in code can make a difference. But the example in the link shows waiting for self destroying thread and this is something which cannot be done with such thread. Hanging is expected behavior.

No. You need separate client for each request if you want to run them in parallel.

This is a slippery slope. Some of use still remember Adobe.

I am not sure I want to go in such subscription model direction. At the end value such subscription provides would be to small for the paid price, or it would have to be extremely cheap (10-20$ a month) with ability to use same Delphi version without forced upgrade. But even then I don't think that would solve the problem. Persistent licenses are the only good model for development tools, nobody will start developing anything (not even as a hobby) in a tool they might not be able to pay at some point and can lose access (even with stepping in and out, as vendor can always change the pricing model). The main problem is the base price for the lowest SKU (PRO) itself which is too steep comparing to other paid and free options available.

When it comes to NX Horizon implementation, it is its simplicity and "lack" of some features what makes it both fast and thread-safe. Because it is simple, it can also be easily adapted or extended according to particular needs. For instance, adding channels can be done by adding thread-safe dictionary which would hold multiple event bus instance, one for each channel besides the default one.

Support for what? There is no free support. Only for installation problems and I don't think there are to many of those. Embarcadero needs to lower low end prices to bring in new users. I doubt there are many prospective new users willing to shell out over 1600$ on new PRO license. Not to mention that there is no upgrade path for existing users with old versions. They need to pay full price.

VS Studio PRO one time purchase is 499$ https://www.microsoft.com/en-us/d/visual-studio-professional-2022/dg7gmgf0d3sj Also VS 2022 Enterprise includes Azure and other stuff. There is also as subscription only Enterprise which is 250$ per user monthly again with basic Azure plan. And there is PRO subscription which is 45$ per user monthly. Right now RAD Studio is extremely overpriced. I cannot comment on Enterprise version and the value it provides, but PRO is literally out of reach for many people who would otherwise more than willing to pay some amount of money comparable to what JetBrains or MS offer on the low end. Not to mention that it does not include Linux compiler which is rather ridiculous. Compare that to Delphi 99$ license with which they started 30years ago (which is around 250-300$) in today's value. If Embarcaderos wants to revive Delphi, they seriously need to change their pricing policy on the low end for PRO SKU and even having additional low cost Community edition with perpetual license would take them a long way.

Beauty is in the eye of the beholder. I literally get dizzy trying to read your code formatting. Even with braces I very much dislike any style besides Allman, and in Pascal, begin and end absolutely must be on the same vertical line for me.

I hear you...

And then you write things like this https://quality.embarcadero.com/browse/RSP-23924 function TBaseFoo.BrokenFoo: IFoo; var LOwner: TComponent; begin Result := nil; if Supports(Self, IFoo) then Result := Self as IFoo else LOwner := Owner; // if block execution will continue here !!!! while LOwner <> nil do begin if Supports(LOwner, IFoo) then begin Result := LOwner as IFoo; Break; end else LOwner := LOwner.Owner; end; end;

Oxygene has plenty of features that would be great to have in Delphi. I wanted to have a case statement with strings for years now. I think it was even reported in the old, old Quality Central. If may look like a simple thing but it makes code more readable. Now when we got if expressions, maybe we wil eventually get case with strings, too.

No, but that is apparently what you are suggesting is enough. Maybe I got what you are saying wrong. But there is way more to code than being able to compile it.