Reminder to self – proposals for Delphi Language Enhancements, a year later
Posted by jpluimers on 2017/12/21
About a year ago, Vincent Parret proposed many [WayBack] Delphi Language Enhancements that a lot of developers feel long overdue.
It sprouted a nice G+ discussion at [WayBack] Blogged – Delphi Language Enhancements – Vincent Parrett – Google+
Now this post is a reminder for myself to check out how Idera lived up to the promises they made in that thread.
Evaluation time…
I just found out that Vincent beat me a few days before I scheduled my post (I wrote my post about a year ago): [WayBack] Just over a year ago, I wrote a blog post where I listed some ideas for enhancing the Delphi language… – Vincent Parrett – Google+
Recommended reading.
Oh BTW: in that thread there was a cool way simulating interface helpers by hardcasting an interface to a record having only one field typed as the interface:
[WayBack] [Delphi] Interface helper proposal – Pastebin.com. By Stefan Glienke. Who else (:
In addition, Allen Bauer chimed in with some great insights.
Finally Document Insight author [WayBack] Baoquan Zuo – G+ posted with more suggestions:
I would suggest Embt consider introducing standard function
NameOfandinterface helper. These two features will fundamentally changes a lot of things with “minimum” cost.
His thread too has some really nice comments.
–jeroen
The Wiert Corner - irregular stream of stuff 
rvelthuis said
FWIW, there is one thing that never comes up in all these wish lists, but which I would find pretty useful: Make it possible to write global (i.e. non-method) generic procedures and functions.These days, you have to make them class (static) methods of an existing class or record type and must qualify them with the name of that class or record. It should be possible (and easy) to make them global too. So instead of
TArray.Sort<Integer>you should be able to have a simpleSort<Integer>.jpluimers said
Oh yes, definitely. It is such an obvious feature, that everybody forgets to mention it. Thanks for doing so!
jpluimers said
A sort of wish: https://wiert.me/2018/01/31/as-delphi-generics-are-not-supported-for-free-functions-wrap-them-in-a-record-container/
Peter Wright said
Ooh – advocating changes in Delphi. Such heresy.
I asked for some support for a number of proposed changes (RSP-13776 – RSP13781). The only response I received was from two correspondents who actually took time out from their busy days to reply that they WOULDN’T be voting for these changes as they are “really non events”.
Now they could have just ignored my post as did everyone else – but “non events?” Well – trivial changes. Easy-to-implement. Having no great impact. And deliberately so. It’s clearing the decks for the grand plan.
And support? Let’s take 13777 as an example. Despite the generally positive responses after Vincent Parret’s post and on the Wiert Corner, the proposal has gathered a grand total of FOUR votes in eighteen months.
And 13781 – extending CASE. “Closed”. 0 votes. Yet one of the items suggested as a development in EMBT’s surveys at some point. And making it case-insensitive is as simple as CASE uppercase(stringname) of…
The criticism? “Impossible. You can’t compare floats with discrete values”. That opens a can of worms. RSP-13792. Resolved “Won’t fix”. Closed. 0 votes. Root cause: The Delphi implementation of a floating-point comparison is faulty as it always compares against an EXTENDED constant, regardless of the type of the variable. Fix that (RSP-19169 – 0 votes) and case-on-floating-point becomes possible to implement.
Arguments about the philosophy of comparing floating-point values to constants assume that the programmer is still wet behind the ears and have no place in the implementation of the language. Sure – produce a warning or help message if it makes you feel better. RSP-13780 (0 votes) may assist. And perhaps develop that into {$WARN W1057 OFF METHOD} to turn the warning off temporarily (for the duration of the method) – Oh – and I’m using “method” here in the light of RSP-13776 (1 vote).
And BTW – case var of 3.069..3.071 would happily detect var=3.07 which should take care of the accumulated approximations.
So – why all the trivial changes? Because if I was to reveal my grand plan – the deprecation of the initialization section (and with it, the parallel-maintenance chore with the implementation section) well, that would enough to give the doubting Thomases heart attacks.
And when? Well – the sooner, the better. The more development that takes place in deviant platforms like OSX and Android, the bigger the job will be.
I had considered presenting my proposals for a revised Delphi syntax at the upcoming ADUG symposium, slated for late May 2018 in Perth (and Melbourne). No keynote speaker has yet been announced and unfortunately, without the attendance of a receptive EMBT representative, all of the preparation work for such an event would be wasted as it would have as much impact on the Delphi world as our monthly usergroup meetings.
jpluimers said
The votes of QualityPortal are vastly down over the ones in QualityCentral for two big reasons:
I disagree with the exact floating point comparisons (that’s hard in any programming language and one of the reasons Java nor C# support floating points in a switch statement), but I agree that the language is long overdue.
Trivial changes can be just as important as non-trivial ones but are usually much easier to implemented. None of the changes are really easy as it is often not just the compiler, but also the IDE, the Kibitz parser and ditto-handling that needs to be changed.
I agree with most of your other reports and upvoted them.
Peter Wright said
Ah, yes. PeterPerfect was a name I used for a while. I was saddled with it in High School, when Wacky Racers was on TV on account of my manners. Perhaps, given the responses I’ve received, many of which border on hysterical denouncement, a wiser choice may have been Cassandra.
I can’t see that the fact that inferior languages haven’t implemented floating-point on a switch statement is a valid reason for not implementing case on any type where +,<,> are valid operations. All that is required is to ensure that for any new range encountered, the endpoints of that range do not fall within any existing specified range and the limits of every existing specified range do not fall within the new range.
And the Kibbitzer currently doesn’t object to case applied to a floating-point, so nothing appears to need to be changed there.
rvelthuis said
What you may like to have probably doesn’t man a lot to others. I personally don’t think that a case with floating point would make a lot of sense. The people who say that comparing to discrete values is pretty useless are right. Sure you could define ranges, but why on earth? For the few people who would perhaps need it a few times, it doesn’t mke sense to change the language. And it would provke many, really many, problems for those who are not so faimiliar with FP and who’d complain that it doesn’t work.
But apart from the fact that it would only benefit a few people in a few occasions, don’t think that any change in the language is easy. We can’t imagine if a “simple” change s really easy to achieve.
Add to that that I think that putting too much in the language will only make the language harder to use. Languages should not suffer from “featuritis”. string-case and even more float-case seem like such rather useless features. Additions should either provide something that was not possible before, like generics, or anonymous methods, or ease certain things syntactically, like the recent improvements for dynarrays. They should not be added just because some other language somewhere has them and they sound so cool to havem even if most people will never need them.
I am all for having useful features like type inference, block-scope variables, inline declaration and initialization, etc. But case can easily be replaced by an if-else-if cascade. It was added, by Wirth, to the language to make such switches easier to optimize, for the old compilers of those days, by sorting the entries and takingranges into account. Such optimizations can’t be done usefully for floats or strings or other non-ordinal types.
Peter Wright said
The fact is that the framework for case is already in place. There is no logical reason why the same framework couldn’t be applied to other types for which =,<,> are valid operations. Why restrict it to integers? Others have expressed applications for using it with strings. Floating-point was immediately jumped on by those eager to find an excuse not to implement a simple application of OOP principles to Delphi itself. Their objection is falsely based – because Delphi’s floating-point comparison is faulty. That then becomes combined with a partly-understood mantra that comparing floating-point numbers can’t be done because of their inherent inexactness. Actually, that principle should only be applied to calculated values.
As for people complaining that it doesn’t work – well, people also complain that their logical case construct doesn’t work (because floating-point is unsupported). I have spent many years as a maintenance programmer and yes, I’m very careful in all of what I advocate that it should be backwards-compatible. That’s why I suggested that if a floating-point compare is used, then the compiler should generate a hint (note: any compare, not just a case) and that the programmer should be able to turn the hint off as experienced programmers regard such hints as noise. Advocating that a facility should not be available because beginners who don’t understand floating-point issues are likely to be confused is like legislating that all bicycles be permanently fitted with training wheels.
Yes – featuritis.. It’s been the absolute death of C, hasn’t it — while stable old Algol just steams ahead. I don’t know of anyone in my local user-group that uses such Delphi features as “Refactor” or “Method Toxicity Metrics” – and I’ve never used an interface. These might seem cool to some, but I’ve never needed them. And case on other-types makes things easier by using the case construct rather than a massive if-then-else structure. It will also object to an overlapping range, which cannot be detected (at least, easily) with your preferred if-then-else.
Ah you like type-inference, so logically you would have voted-up my
methodsuggestion, which is simply method-type inference.jpluimers said
The
casestatement is not restricted to integers. It is restricted to ordinal types. The limitation is for a reason: the framework was written for that particular problem domain.Extending the problem domain into areas where the
=andoperators are exact is feasible so they could do it if they can claim enough time at their compiler engineer: https://twitter.com/yooichitagawaYou already observed that for the IEEE floating point types Delphi supports, those two operators are not exact, especially not when written out in decimal notation (they could be if there was an IEEE float type with arbitrary-precision arithmetic and Delphi would support it). This inexactness even holds for calculated values as the exactness of floating point operations highly depends on the order in which they are being performed, intermediate storage, various hardware implementations and IEEE settings which means determinism is a very tough thing.
This all apart from the fact that if a case statement would support floating point comparisons, it would introduce even more oddities. Explaining those to (even highly experienced) programmers that are already confused by comparing floating points with the normal Delphi comparison operators is going to be a very tough job.
I think the gain of being able to do floating point checks in a case statement is far outweighed by the extra efforts needed.
It is far easier to write a (set of) classification function(s) where you program (and document!) the mapping of floating point ranges to ordinal values, then select those in a case statement.
An interesting read on comparing floating point numbers from an IEEE perspective is https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
On determinism with floating point data types read https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/ and https://gafferongames.com/post/floating_point_determinism/
Your other language suggestions are very similar to what the Oxygene language does. I like that language a lot but is not fully compatible with the Delphi language and will never be.
Joseph Mitzen said
“So – why all the trivial changes? Because if I was to reveal my grand plan – the deprecation of the initialization section (and with it, the parallel-maintenance chore with the implementation section) well, that would enough to give the doubting Thomases heart attacks.”
If you could bring Delphi into… well, the 1990s… you would be an eternal hero of the language! Single-pass compilers and all of their limitations (and inability to perform complex optimizations) are anachronistic.