Stefan Glienke

Guess what - there are even rules that will tell you when you access things without using this in static code analyzers - and there are good reasons to do so (although I personally dislike it) Speaking of programming language design - you never can make everything perfect and there are always features that have some "be careful with it!" tags on them. However features that are so often accused of causing problems or confusions can be declared bad. And yes, every language has them and every responsible Developer should know when it safe to use them. Fun fact: I just recently consciously used goto because it yielded a noticable performance gain and rewriting the code without it would have been a massive undertaking resulting in more complicated code than just putting a goto there. And no, no raptor attacked me (yet...)

It's not about proper naming - its about newly added members creeping into the with scope - as happened when TRect got Height and Width properties! It was perfectly clear that Top, Left, Right, Bottom referred inside the with belonged to the "withed" rect variable and Height and Width to something outside - now those got added to TRect and boom.

There are currently no plans to do that as far as I know. Apart from them being way to busy with the tasks already at hand as you can see it would not only bring benefits but the disadvantage that the LLVM compiler is slower than the classic Delphi compilers. I am no compiler engineer so I can't say if that is just poor coding in the frontend (which Embarcadero developed) or the backend. My personal guess: a mixture of both. For example I don't know if the developers of the Delphi frontend are following all the guidelines given. Also the LLVM compiler has some issues with exception handling (source). IMO as much as I like the idea of the LLVM architecture which gives incredible flexibility it still has some way to go. The linker for example I have been told is not as good as the linker in the classic compiler when it comes to unused code removal - but I have no personal knowledge about that. What you certainly can see is that the LLVM based compilers produce quite some big intermediate and also sometimes final binaries (even more so when a lot of generics come into play)

Looks like some entries are not properly wired up to the new hierarchy within the options dialog. You can see that the Delphi related entries in your screenshot show (Formatter | Delphi) which actually needs to be (Language | Formatter | Delphi | ...) just like those for HTML for example.

+1000 And then also introduce proper namespacing and ways to alias things (not only non generic types) at the consuming side (for example)

IMO not - the beauty of MVVM comes from things that I have not seen yet seen achieved in Delphi. It requires special support for every existing control by either subclassing or other ways, CoC and existing data binding solutions are very brittle and easily break when renaming things, functional approaches like done in ReactiveUI are almost impossible or create clunky and bloated code.

And yet that idiom works even better in the Web where you can easily blend data binding into the DOM like all those MVVM frameworks over there do.

After a lot of research and experiments I believe that MVVM as it works in other languages which makes it desirable to use is not possible in Delphi at this point. (*) The main reasons for this are lack of language support for things that are achievable in a very compact way in other languages and the way the main UI frameworks work in Delphi. Considering the history and existing support for datasets everywhere I think that separation of business logic and UI can be achieved rather by utilizing this to be able to access plain object with their properties over a TDataSet API to make any DB aware control work with them out of the box giving you all the support that has been there since Delphi 1. (*) "WTF is he talking about?!" - just take ReactiveUI as an example - implementing this in Delphi in a nicely usable way is imo almost if not entirely impossible.

The original code in QualityToInt causes a System.LoadResString for each "case" it checks every time you call that method and System._UStrEqual for the equals check. Neither of those two methods have changed between those versions according to the diff I just did. However LoadResString calls quite a number of other functions that I did not check for changes. I would say a dictionary is pretty much overkill here for those 3 strings - it only is faster because you eliminated the (as I assume) LoadResString calls every time. Try initializing values you compare to only once instead of comparing against the resource strings. I am pretty sure that will beat the dictionary.

Assuming that you don't need to use that code from C++Builder just turn off header generation.

No, but then you still have to add the library paths (as I always recommend instead of recompiling the third party sources every time with your application) - if that would be part of the IDE compile/build now that would be great! It is not outdated it is just there for Delphinus - as you can see it has the latest release (1.2.2) - since Delphinus supports External Timelines the github repo just has the files for Delphinus, the sources are then taken from bitbucket. Compiling for all supported Delphi versions is just one click instead of opening in each IDE and compiling for half a dozen platforms (this mostly applies to me when I need to make sure that none of the dozen compilers chokes on some code).

This is like asking "I made a printout of that document last year why didn't it update when some people changed the pdf" 😉 A git clone does not update itself - think of it as snapshot - you as the clone owner are responsible to keep it up to date. I think there is no point in making a clone(*) anyway unless: - you are afraid of the repo owner just deleting it (and even then the nature of git would allow everyone who has a local clone just to push it back to a new home) - you want to maintain your own modifications (either for keeping them for yourself or contributing back) (*) sorry, when I wrote clone I actually meant fork - I was assuming that you always keep a local clone up to date or at least fetch it regularly (most git ui tools do that automatically anyway) to see whats new on the origin

I still don't see a way to repro this behavior on the Delphi side because both RSP entries that are referenced in the patch are C++ ones. So chance is high Andreas won't be able to repro and fix either.

Then submit a pull request with the necessary changes to get rid of the hints. P.S. Btw proper use of git will not overwrite your local changes fwiw

How can a name collision between TTMSLoggerLogLevel.Exception and Sytem.SysUtils.Exceptions be an IDEFixPack issue? It has even been reported already: https://www.tmssoftware.com/site/forum/forum_posts.asp?TID=8402&title=enumeration-names

Looks pretty much like -O0 assembly

Well then the issue is not only about that one but also about other toolbars because if you look carefully the rightmost button in the debug toolbar also has a different icon. What happens if you go into Customize and click Reset for those toolbars?

I am pretty sure it's a different layout that gets loaded and that it in fact is not the "View/Ansicht" toolbar you are pointing at in the bottom screenshot. Simply right click and check if its checked/visible

Use Rust if you want that :)

Not true - this ain't .NET or Java that raise an NPE as soon as you reference any member - it can very well call non virtual methods and then eventually raise some AV which you then need to decipher (everyone knows what an access violation at 0x0071f2a7: read of address 0x000000f7 means, right?)

Any approach like this in Delphi would be impossible or suck (because it would need to be stringly typed) because Delphi does not have lambda expressions and generic extension methods.

Learning about one of the most powerful and free controls the VCL has to offer - yeah what a waste of time 😜

To get a sophisticated answer you need to actually describe your situation properly and not just say "invalid values" - invalid in what context? Restricting UI from entering any invalid values can go from controls that don't even allow it, show a marker that their value is wrong, not allowing clicking ok/next to showing an "following fields have invalid values..." dialog. Declaring guard clauses in code for functions and methods that restrict passing any invalid input is a different thing and in that case I would always go with exceptions of a certain kind (EInvalidArgument or similar) either handwritten or by using some guard clause helper. If the programming language allows I would push this further by restricting the parameter types to only allow what is valid and for instance use decicated domain types instead of for example type string for an IP address but a dedicated TIPAddress type.

Virtual TreeView