Stefan Glienke

Oh gosh... As for what temporal coupling means - use google before I spend my time explaining it to you - someone else probably already did a better job anyway. P.S. Your use of "class field" and "class method" is wrong - what you are referring to are instance fields and methods. type TFoo = class fName: string; // instance field or just field - because every instance has its own class var fCount: Integer; // class field because there is just one - basically like a global variable but only visible inside of TFoo procedure Bar; // instance method or just method - can access instance members (like fName) but also class members (like fCount) - Self refers to the instance of TFoo class procedure SomeStuff; // class method - can access class members (like fCount) but not instance members - Self refers to the class itself - here TFoo - many other languages don't have something like this class procedure MoreStuff; static; // static class method - can also access class members but has no Self end;

I wish when they did (most of all that .NET API inspired copies happened years ago) they actually did not mindlessly copy it: - Monitor... I think C# at that time already had the lock keyword which does all that underneath to avoid boilerplate, - generics and mostly type constraints - understanding that class in C# is a constraint on reference types and not only on classes and that struct is a constraint for value types. Porting that properly to Delphi which has kind of hybrid types such as string or dynamic array. - System.IEnumerable and IEnumerable<T> and that in Delphi without a rooted type system it does not make a bloody sense to inherit the generic one from the non generic one - System.IOUtils - plagued with ton's of bugs and a rather terrible API and performance I think there are more examples. .NET is not perfect but I am amazed how much effort goes into it - how APIs are being improved (and yes mostly without breaking them - the issue with inventing and dropping things is mostly in the eco system that builds upon it). Damn they even care about binary size for their guard code! (see the comment in https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/ThrowHelper.cs) Recently they refactored many APIs to use Span<T> to avoid unnecessary allocations - while in Delphi we still allocate strings all over the place when using the stringhelper methods for example and only the people that care for performance then do all that ugly mess with PChar.

My first impulse was pure function! as well but that depends on how SearchByFieldName is implemented - ultimately this looks like it mutates internal state. However you should avoid temporal coupling as it leads to hard to maintain code.

Sure but as it stands and even with LSP support in 10.4 Visual Studio Code with OmniPascal (not sure what you offer for code tooling in your package) even with its glitches runs circles around what you can do in RAD Studio coding and code navigation wise. So doing all form stuff and debugging in RAD Studio while doing the pure coding in Visual Studio Code (yes some people don't just slap components on forms and implement event handlers!) is often the superior experience.

I watched the video series and I have to say it unfortunately did not do a very good job showing why this is a big deal. Tedious copying and modifying the template and all that. When I watched this I thought by myself "I am a noob with web development but probably would have slapped this together faster with something like knockout.js or similar. Don't get me wrong - it looks interesting - just the video series was a bit off-putting. What get's me more interested here is if you could use the designer to design VCL forms within VSC - not asking for the entire featureset and behavior at designtime but just the basic align, anchor, size/position shebang.

No, it's upwards compatible - an unknown version identifies as latest known one including all feature defines

The general hints in the readme are very valuable (and made me revisit some of my ifdef checks) - apart from that it reminds me a bit of https://xkcd.com/927/ Yes, jedi.inc is long and unwieldy at times but it got everything commonly needed - in case it does not - wouldn't it be wiser to add that instead of rolling a new thing? Apart from that the prefix CAPS is kinda misleading imo - why not go with the HAS_ or SUPPORTS_ prefixes? Oh a note on your comment for bitness checking - the example does not entirely match what you describe, it specifically checks for x64 - so x86 and arm would go in the else. Bitness checks would be CPU32BITS and CPU64BITS or whats also common to check SizeOf(Pointer) = 4 for 32bit. Historically the checks are rather for x86 specifically to implement something using asm and then pure pascal in else.

From the looks yes because it makes sense - however you already cloned a repo with it when SourceTree did not even finish starting...

I did not read the article but a comment like this can only come from a person that has never worked in a team or on multiple features/versions. Or they actually did and had a total mess managing their stuff - I remember several video games in the past where bigger feature updates constantly introduced regressions that were already fixed in previous bugfix patches simply because they forgot to reapply those commits to their feature revision (no guess, this has been confirmed by the devs)

They are all available on all platforms and got introduced in XE3 - feel free to copy excerpts from Spring.pas - or some other libraries that have similar implementations For reference: https://bitbucket.org/sglienke/spring4d/src/ffee3360a2e8cb9ae5311621a745bb9ed809870f/Source/Base/Spring.pas#lines-2729 And let me know if you find any defect 😉

Currently very much enjoying this feature while running unit tests with a lot of exception checking under the debugger! 👍

Just a suggestion from someone who also wrestled with supporting multiple Delphi versions in his library: Use AtomicXXX throughout the code and declare them for the older Delphi versions that did not have them yet - that way you get the best code generated by the newer compilers that know about these intrinsics rather than putting indirections for everyone in order to be backwards compatible.

The current implementation of CMRs is full of lost opportunities: In C++ you can prevent copy/assignment simply by removing the copy/assign operator and it will not compile if you try - in Delphi we have to use runtime exceptions, yugh... In C++ you can directly access members on a unique_ptr or shared_ptr because you can override the * and -> operator - in Delphi you have to make some property to access the wrapped object. Oh, and thank you CMRs for making my code slower which does not even use them!

Picking up tests solely by [TestFixture] only works if you use {$STRONGLINKTYPES ON} or somehow reference the testcase class - otherwise the linker will strip it. That is why TDUnitX.RegisterTestFixture usually is a better choice (imo)

Reported and complained about numerous times - like https://quality.embarcadero.com/browse/RSP-21023 I think Allen Bauer somewhere explained this a bit more detailed but here is the short version I remember: The compiler internally takes some shortcuts and the part that produces the warning does not know that the var parameter it sees was originally meant to be the function result. My advice: spend a few bucks for FixInsight - it will catch this and other things the compiler does not.

Let's claim that our code is the critical 3% 😉

In the C++ community people usually tell you the compilers are incredibly smart (mostly referring to gcc, clang, msvc or icc) and you should not bother but just know some C++ tricks (constexpr wherever possible and alike). When talking about Delphi it would be an insult to most developers calling the compiler smarter when it comes to detecting patterns and optimization. However - unless you write core libraries like Arnaud or me you usually don't care.

No, it's not the same codegen, its a test and jnz less. You don't want forward jumps taken in the common case. Also a very important fact (I think it was mentioned before) - depending on where the compiler puts the code the hot loop code might cross cache lines - that slows things down significantly and can happen when you add or change unrelated code in other routines or in this routine - such as a check for Length or similar. When I let the routine start at some 64byte aligned address the loop body will cross cache lines and be slower. To my knowledge there is no way to control the alignment of generated executable code so that you can force hot code into a single or as few cache lines as possible.

If you really worry about performance in this area then don't use TCriticalSection but embed the TRTLCriticalSection (or the appropriate thing for POSIX) into the object where you need it - that way you also eliminated an indirection. And make sure that your allocated memory from the memory manager is aligned cacheline friendly (it won't by default)

RAD Studio Project - every Jira project has a unique code

@Rollo62 Reminds me of Zen of Python

Slightly OT: Use whatever you want for private projects or within a company but please - whenever someone does open source don't turn off possible contributors by having to install yet another VCS. Git has won, deal with it!

Now that is clearly shorter than calling dcc32! /irony off

I challenge you to write this method in a more performant way than what it currently is without completely turning it into an even less readable mess: https://bitbucket.org/sglienke/spring4d/src/534d63bccd0891d165d6cee1cbfff18df790661e/Source/Base/Spring.pas#lines-10122

@vfbb Depending on the tree the balancing is pretty damn efficient - but the memory layout after a few iterations can be totally screwed up which I mentioned earlier. But as always it depends - there is no "best for everything" data structure or algorithms but you typically want the "reasonably well for most cases" (bonus if they are "not exceptionally terrible for some rare cases"). Typically the decision is if the thing is often read or often written. If both is the case you have to evaluate the costs of going down the rabbit hole of implementing some special case data structure or simply roll with some standard implementation.