Stefan Glienke

They do by possibly specifying a capacity when creating one. Should I depending on that number either call SetLength which uses GetMem or allocate the dynamic array memory buffer myself? I would rather like to avoid that because that might get quite complicated when we are talking about resizing. That is what I was aiming at - making claims of how x is bad and y is better is all good and sound but what are the concequences for developers that want to benefit from these potential benefits - or does it not matter at all.

The alternative to Italic... scnr

As a library developer I have this question after reading all this: how does this affect me. For example collections are an essential part of spring4d and they can be of any capacity from just a few items which fit into a small block up to collections that hold thousands of elements and where SetLength causes the used GetMem to use large blocks. So if anyone claims that the way the MM does it is not good the solution for many places that allocate variable size of memory is not to put if size < x then getmem else virtualalloc but to solve this properly inside of GetMem/the memory manager. Especially since GetMem is indirectly called by many things such as SetLength - if you directly allocate memory for your own sure you can choose one or the other.

Yes some are written to disk but usually not commonly used memory - especially not when there is plenty of RAM available. The article even says:

Look into the implementation of System._GetMem and compare that with System.GetMemory and you know the answer.

Not sure you missed or ignored it but I'll throw this in here for completeness and because it's free: Git Extensions.

You either keep wondering or you simply google it and find this for example: https://stackoverflow.com/a/2477026/587106

Ask him nicely how you can help him get it out for 10.4 and maybe he'll do.

DDevExtensions does it indeed.

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% 😉