Stefan Glienke

Amazing amount of unittests

*puts sunglasses on and holds a pen up*

Yes, the need for those given that you just check for different cases on the same thing (typical if x is button then ... else if x is edit then ... else if x is ... cases) just comes from case of syntax element being of limited use only. Those horrors would not be worse than half a mile of if-then-else-if "ladders". Especially since in those you can easily hide some non conform pattern which can easily get unnoticed - for example checking x for 10 different types but then in some else if check y for something...) Language improvements of the category "syntax sugar" (i.e. something that could be done before but in a more convoluted way) should improve code readability by reducing the ceremony around the essence of what the code is supposed to do.

I think other languages also support this natively but here is the doc from C#.

The real issue I have with this style is that we have to write code like this in the first place because Delphi does not support pattern matching.

Yes, it is caused by loading the grid and then setting the viewtype to bandedtableview (I was referring to the BandedTableViewDemo Mainform) which then causes CreateView to be called which eventually runs into that shortcut thingy.

FWIW that exception also occurs when opening the MainForm in the IDE. And after that the IDE is trash and raises AV left and right Here is the relevant call stack: [50177955]{rtl260.bpl } System.Classes.TComponent.ValidateRename (Line 16888, "System.Classes.pas" + 4) + $3 [50178110]{rtl260.bpl } System.Classes.TComponent.SetName (Line 16979, "System.Classes.pas" + 7) + $3 [5006205D]{rtl260.bpl } System.@UStrAsg (Line 26353, "System.pas" + 19) + $0 [2C3075A3]{DeveloperMachines.FireDataGrid1.bpl} Firedatagrid.TFireGridViewBase + $4B [2C2919EE]{DeveloperMachines.FireDataGrid1.bpl} Firegridtableview.TFireGridTableView + $16 [2C2689C2]{DeveloperMachines.FireDataGrid1.bpl} Firegridbandedtableview.TFireGridBandedTableView + $16 [2C3014EB]{DeveloperMachines.FireDataGrid1.bpl} Firedatagrid.TFireCustomDataGrid.CreateView + $2F [2C301546]{DeveloperMachines.FireDataGrid1.bpl} Firedatagrid.TFireCustomDataGrid.SetViewType + $46 [50126816]{rtl260.bpl } System.TypInfo.SetOrdProp (Line 2878, "System.TypInfo.pas" + 37) + $4 [2100E952]{designide260.bpl} DesignEditors.TPropertyEditor.SetOrdValue (Line 840, "DesignEditors.pas" + 2) + $E It is caused by the call to TShortCutList.Add with s being 'Ctrl+''=''' which causes TextToShortCut return 0 Knowing that = is on the 0 key on a german keyboard it might make sense that this shortcut cant exist, technically it would either be Ctrl+0 or Ctrl+Shift+0 Just looked at a coworkers US layout keyboard to make sure - they have a '=' key. So you need to create those shortcuts differently.

"This also appears to affect OmiThreadLibrary" is very likely to be false - nothing in System.Threading is affecting the OTL at all - if the OTL reveals a similar behavior then it's most likely due to the solution and combination of parallel tasks itself. The PPL is a story of broken stuff since the first version. The issue in this particular report seems to occur because the threadpool spins up to 100 (by default, you can change that) threads as it sees that CPU usage is still low (not sure about the situation in the real code as that very likely does not use Sleep) and then is probably way more busy managing those than actually doing work.

To make this clear - there are - the "classic" compilers where everything is done by Embarcadero: Win32, Win64, OSX32, iOS Simulator - the "nextgen" compilers that use the LLVM architecture - that means they have to write the so called frontend which translates the code into LLVM IR - what they don't have to do themselves is the backends for all the various platforms and the linker. Now before anyone asks "well if they don't have to do the backend and can just use all the supported platforms from LLVM" - they still have to do all the system/platform specific code in the RTL for every platform.

At least its not "XE 10.3.4"

No, that would not release either - thats one of those bugs people keep reporting since ages and Embarcadero refuse to fix - I think @Dalija Prasnikar remembers the according QP entry. FWIW unless the comparer needs its own state you don't even need to create your own class, just pass a function(const left, right: T): Integer to TComparer<T>.Construct fwiw in Spring I added overloads to all methods taking IComparer<T> to also directly accept that - makes using them way more comfortable.

Mixing of object and interface references with a const interface param. Solution: declare the Comparer var as IComparer<TXTColumnPosition>

What the hell are you talking about? CLANG is the LLVM frontend for C++ - so basically what Embarcadero did for Delphi. The difference is that I don't know how many people are working on CLANG (including people from Apple, Microsoft, Google, ARM, Sony, Intel and AMD) instead of one and a half men for the Delphi one...

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).