Stefan Glienke

Ok, if we are talking other languages: best is to not be even able to compile the code or get warnings when the static code analysis cannot make sure that these conditions are met - for example using non nullable reference types.

I disagree but I am not going into yet another discussion about this.

I see this many times I put a breakpoint into a line with an inline variable declaration - it looks like some debug symbol issue so the breakpoint is not set into the proper instructions but into the prologue code the inline declaration brings with it. This can be very annoying and confusing indeed.

They should just make typed const true consts by dropping that writeableconst - or for the sake of backwards compatibility introduce a new switch $TYPEDCONST that when enabled turns even typed consts into true consts that even if you try $J+ won't be writable.

If you in fact read carefully what I wrote in my first post in this thread you would have noticed that I was merely referring to using attributes for passing test data to unit tests (which probably your made up TestAttribute made me believe you were trying to) and which the snippet showed that I posted - you never mentioned that in fact you are trying something different with your approach. And in this context you just showed it even does not look like a good idea because apart from not working it would even create 2 indirections - you would need to declare all the const records somewhere and then pass those to your attributes. If all the data being passed to attributes gets so complex that you feel the need to make compound types from them then I would rather consider writing an Init method where I do all this - compiled code, no attribute/rtti overhead, easily testable, done. Or if you don't like writing code - then make a custom component editor for your TGridSet class that you can then edit in the designer - add verification logic and so on.

Of course it does not - because it's not regularly invoked but executed via RTTI taking its arguments from at compiletime specified memory - see System.Rtti.ConstructAttributes I would agree if it would reference production code method names that might be subject to refactoring without knowing that some test code references to them but in this case the referenced method is part of the test code and you don't usually rename those and even when they are very close to each other so its more unlikely to miss the reference. Anyway feel free to ignore the obvious and already proven to work fine solution and look for an impossible one :)

Judging from the performance of the mobile compilers over the years I would say: no

I just noticed that the default shortcut for "View->Debug Windows->CPU Windows->Entire CPU" did not work since I installed MMX. After first missing the key bindings directly in the "Key bindings" node (I only looked in the 2 sub nodes) I found its assigned for "Copy Entity" Now sure I could just reassign to something else and then when the next shortcut conflict happens I do that again and so on. Or the plugin itself could actually check if it overrides or conflicts with any other shortcuts (well between 3rd party plugins it would be nice but mostly I hate when plugins override default shortcuts from the IDE - GExperts also does that, grrrr!) The best solution in this particular case would even be to be contextual (I guess that might be complicated but I thought I just mention it) as during debugging it would make more sense to show the CPU view but when not debugging that does not do anything and when in the editor I might want to copy the entity.

Passing a token to the task that can be checked and raise a special "task cancelled" exception when that is the case which gets cought in the task executing layer. Of course write your code executed in a task so that it can be cancelled via exception

15 beta - and shortcut can also have changed years ago. I would expect it to respect those of an already existing installation/config rather than changing them. So the change would only happen for a new install.

For me it was. As far as I can see GExperts just lists actions with a shortcut - not all shortcuts that you can register via OTA. For example most prominently it does not list Ctrl+#. If you are using Documentation Insight - that one also assigns Ctrl+Alt+C but is not listed by GExperts.

Reading the documentation is underrated these days, eh? http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants#Typed_Constants To solve this particular case of providing structured data to unit tests via attributes I am referring to an approach where you specify where to get the data from in the test attribute and write the code that then does not have to be const in methods that are accessible via RTTI. Here an example how to use this with the Spring.Testing extensions for DUnit: https://bitbucket.org/snippets/sglienke/pe7xAK/dunit-with-external-test-data The approach itself is borrowed from NUnit - see https://github.com/nunit/docs/wiki/TestCaseData

Yeah, minimal... like dealing with every possible language for weekdays the mail could contain regardless the local language of the system the software is running on...

The opposite - I suggested %localappdata% but you suggested the better %appdata% which roams - registry does not by default (to my knowledge)

One reason lies in the answer you just gave opposed to using %localappdata% ... the others you can find on google from various sources.

Storing dialog sizes and positions in the registry is not best practice imo and should be stored in %localappdata% or similar

The return type combo box seems to be some special thing The drop down arrow looks different from the usual combobox ones and the "set to void" button next to it looks to be a little smaller than the usual toolbar buttons

Yes but don't ask me why - I've been told that some of the optimizations slow down compile time even more than already happening on LLVM based compilers compared to the classic ones but fwiw I would not care for longer compile time on release config.

If they hardcode turn off many optimization options in the LLVM backend it won't produce any "as fast as it could be" code...

It does. The reason it's not supported is because Delphi Interfaces are COM based which restricts this. A generic type parameter on a method is just that: a parameter - but resolved at compiletime to provide type safety. You probably have never used any language where interfaces easily support methods with generic type parameters - otherwise you would not have this opinion. FWIW this is one of the reasons I so strongly wish for interface helpers because then it would be possible to add such methods via helper - the COM based interface itself is not affected but you can easily augment them with such methods. In 2014 I wrote some code that shows how such interface helper methods could be invoked similar to record helpers: https://pastebin.com/acp2i645

There is no DSharp version compatible with Spring4D hotfix 1.2.3

It's not about the level of nesting but about the number of cores you have and if the outer loop already produces enough threads to utilize all of them. If that's the case it does not make sense to parallelize even further because your CPU is already saturated

You are right - now I wonder why that was not used - probably the author of that code also forgot about those 😉

It's also a bit irritating that Delphi with all its different sized ordinal types does not have built-in clamp functions to this day...

The only instances the container takes ownership of are singletons