Fr0sT.Brutal

Isn't window a kernel object? THandle is generic indeed, WinAPI has different typedefs for each object. OTOH, using WinAPI typedefs means sticking to Win platform only, which is less actual now as language becomes x-platform

Anyway if a user has admin rights in your system, he is able to dump process memory or even debug it. If he hasn't, encrypt your data and transfer it in any manner.

Why it took him so long? These versions are very similar. I could understand complexity of D7=>D2009 migration due to Unicode; x32=>x64 is even easier in most cases. But 10.2=>10.3?

Sometimes I miss XML vis-er; JSON one might be useful too. But there's a number of implementations available so they are unlikely be implemented

I wondered about it too but the truth is that I rarely need something more than StringList and TDateTime visualizers. Anyway yours is cool!

I was trying to express that final value will be uncertain, probably I did it unclear. Nevertheless if we're talking about for-in loops, I think nothing dangerous would happen. It's just a syntax sugar for while iterator.GetNext(variable) do ... so the value after the loop will be initial (if list is empty) or equal to last item in list. AFAIK that warning is actual for simple for loops only as compiler can optimize the counter with CPU register. This is not the case with for-in loops of course. You use inequality sign in an enemy language's style ! I suspect you're a C++ spy here in the heart of Delphiland xDDD

Ok, what will happen after the loop? ToolInfo will have has value of a last item in the list OR a value it was init-ed with (if list is empty) OR some value found in the list. So how the code below the loop should distinguish those cases one from another?

Being oldschool is not tightly connected with age 😉 moreover, in today IT world, one could be called oldschool just for using 1-year-old techniques )))

Just as I suspected. Depending on DB capabilities, this could be solved using temporary tables.

Bad idea. What if "if" is never triggered?

I believe mORMot has the fastest implementation of everything :)) There also big libs like Griijy , TheUnknownOnes etc. Check https://github.com/Fr0sT-Brutal/awesome-pascal

As a single developer, I sometimes rewrite my projects to newer technologies without a significant improvement just to keep myself up-to-date. But I can't understand why business decides to rewrite a working and tested project written on "good old lang A" from scratch using a "brand new shining lang B". Especially considering that "lang A" is pretty alive and developing. Geek coders sometimes tend to rewrite things just because existing stuff uses a language, libs or even a license they dislike but a company with customers shouldn't be such geek.

Well, for the purpose of bringing global var/const init capabilities into the code section they could serve quite well at the same time not causing too much eye pain to oldschool guys 😉 Foo(var r: TSomeRec = ( fInt: 123; fStr: 'bar' )) (at least as I imagine it - haven't tried 10.3 yet)

I saw multiple opinions that such big IN's are bad design. Where they come from?

Foo( [ Bar([1, 'First', 0.01]), Bar([2, 'Second', 0.02]), Bar([3, 'Third', 0.03]) ]) where Bar is function-"constructor" or, in newer Delphis, you can use inline variable inits

You're absolutely right but careful handling of OOM errors will be far from trivial and probably will not ever happen (considering OS virtual memory mechanism). And there's little an app could do in such case. Nevertheless, I'd read any resources on this subject with pleasure. And I don't think this design is good 🙂

Indeed. Everything depends on those classes, whether their creation could fail or not. Anyway the ability of exception in constructor seems to me like a hidden trap (not talking about alloc errors on low mem available - I suspect only a few specially prepared programs could survive this case).

I'm not sure WaitFor* functions have lesser granularity

With current construction you have to create an instance in the outer scope thus enlarging the code. I'd move all processing to ctor, maybe this way constructor try inherited Create; .. Finst := Inst; except Inst.Free; raise; end; or this constructor Finst := Inst; inherited Create; .. So that caller code would be just MyInstance := TMyClass.Create(TSomeOtherClass.Create);

This kind of descriptions are priceless for any unit that is something more than a set of various utilities. The same for quick overview of some classes. Sadly those who write such descriptions are very rare 😞

Nice solution as well if you control creation of parent class. For example, there could be a middleware class that contains HTTP server that has client classes defined. You can't control creation of HTTP server but can modify its props so if HTTPServer.HTTPClientClass is accessible you can extend client objects.

@Stefan Glienke thanks, I thought a general term was meant not the language construction. Haven't looked at these new features yet

There was several cases when I looked and thought "what I was thinking, this stuff is ugly and non-optimal, I'll fix it in a minute", but after N hours of redesigning the code I realized "Aaaaahhh I meant THAT thing!" and reverted old code but now prepending it with extensive comments entitled with "There be dragons" magic phrase xD

Sure, just cast them to Pointer

https://github.com/hunspell/hunspell/blob/master/src/hunspell/hunspell.h contains about 10 functions, one of the most short APIs I ever seen xD