Jump to content
David Schwartz

language updates in 10.4?

Recommended Posts

I'm curious if anything has been said about language enhancements in 10.4.

 

I tend to avoid language enhancements, but I'd love to see nullables as well as a ?? and ??= operators, and even a ternary ( x ? y : z ) operator, esp a ternary operator that works with nullables.

 

I've seen that nullables are in the pipeline, but the overviews are getting so high-level that it's nearly impossible to discern any specifics.

  • Like 1

Share this post


Link to post

I've collected some info on 10.4 here: https://github.com/ideasawakened/DelphiKB/wiki/D27.Next.10.4.0.0

 

Specifically, managed records was pushed off for 10.4: http://blog.marcocantu.com/blog/2018-november-deferring-managed records.html

And it was confirmed recently as coming in 10.4: https://community.idera.com/developer-tools/b/blog/posts/get-ready-for-the-10-4-beta-with-update-subscription

 

That's all I've seen specifically for language enhancements in 10.4.0 but they may surprise us.  

 

I'm looking forward ti VCL Styles + High DPI improvements in 10.4.   The language server protocol will likely open up a new set of tooling for the IDE, which might be cool if it works.  

 

Beta should start 'very soon' - supposedly sometime in March. 

 

 

 

  • Like 1
  • Thanks 1

Share this post


Link to post

I'm looking forward to a ton of bug fixes and performance improvements, for the IDE, the compiler(s) and the resulting executables. Considering the code name "Denali" is based on a mountain in Alaska a feature freeze could sound likely, but I doubt it. When Delphi Anchorage is finally released it will have some cool new features along with the obligatory cool new bugs... *Sigh*

  • Like 1

Share this post


Link to post
46 minutes ago, Sherlock said:

I'm looking forward to a ton of bug fixes and performance improvements, for the IDE, the compiler(s) and the resulting executables.

The eternal optimist

  • Haha 2
  • Sad 1

Share this post


Link to post
Just now, David Heffernan said:

The eternal optimist

That's me :classic_cheerleader:

  • Like 2

Share this post


Link to post

The main change about the language would be the full ARC removal.

The memory model is really part of the language, to my understanding. It is just as vital as to operate with "class" itself.

 

Pure unfair FUD trolling remark: managed records are available in FPC trunk since a few months, and I guess EMB doesn't like to be behind an Open Source compiler. 😉 

 

We implemented Nullable types using variants, and integrated support in our ORM. It has the advantage on working since Delphi 6, with low overhead, and good integration with the pascal language.
See 
http://blog.synopse.info/post/2015/09/25/ORM-TNullable*-fields-for-NULL-storage - back from 2015!

 

  • Like 2

Share this post


Link to post
Posted (edited)

Managed Records were removed at last minute for 10.3 and postponed to 10.4

Edited by Markus Kinzler
I meant records
  • Like 1

Share this post


Link to post
48 minutes ago, Markus Kinzler said:

Managed Reports were removed at last minute for 10.3 and postponed to 10.4

You either mean management reports or manged records... not sure which. Hmmmmm

  • Haha 1

Share this post


Link to post
3 hours ago, Markus Kinzler said:

Managed Reports were removed at last minute for 10.3 and postponed to 10.4

I'm not the only one who runs out of coffee! :classic_cheerleader:.

 

 

Share this post


Link to post
7 hours ago, Arnaud Bouchez said:

The main change about the language would be the full ARC removal.

The memory model is really part of the language, to my understanding. It is just as vital as to operate with "class" itself.

 

 

Ah yes, I neglected to mention ARC removal in my summary.  I guess I assumed that one was well known as coming in 10.4

 

 

Share this post


Link to post
Posted (edited)
20 hours ago, Stefan Glienke said:

Not typesafe, thank you bye.

What do you mean? That you can put a string to a TNullableInteger?

At least under FPC they are type safe: you are required to call NullableInteger(1234) to fill a TNullableInteger variable - you can't write aNullableInteger := 'toto' - or even aNullableInteger := 1234.

Delphi is more relaxed about implicit conversions, so under Delphi it is indeed not typesafe, since you can write aNullableInteger := 'toto'.

Edited by Arnaud Bouchez

Share this post


Link to post
  TNullable<T> = record
  public
    Value: T;
    IsNull: Boolean;
    class operator Implicit(const Val: T): TNullable<T>;
    class operator Explicit(const Val: T): TNullable<T>;
  end;

?

Share this post


Link to post
Posted (edited)
3 hours ago, Arnaud Bouchez said:

What do you mean? That you can put a string to a TNullableInteger?

At least under FPC they are type safe: you are required to call NullableInteger(1234) to fill a TNullableInteger variable - you can't write aNullableInteger := 'toto' - or even aNullableInteger := 1234.

Delphi is more relaxed about implicit conversions, so under Delphi it is indeed not typesafe, since you can write aNullableInteger := 'toto'.

Interesting - even with {$mode delphi} it does not allow that - probably it's yet another of those bazillion switches of FPC to make it behave similar to Delphi - not that I would ever care.

Anyhow this is still a thread about Delphi so your approach is not sufficient here imo.

 

@Fr0sT.Brutal It's a little less simplistic than that but basically yes.

Edited by Stefan Glienke

Share this post


Link to post
Posted (edited)

I don't care about nullables so much as a more efficient way of writing code that tests for a NIL value and stops rather than raising an exception, so you don't need to have 

 

if Assigned( xyx ) then 

 

all over the place to prevent exceptions. Nullables seem like a back-door way to get support for something that would save quite a bit of time and coding that isn't going to be added to the language just because it's really useful.

 

There are so many idiomatic phrases we use habitually simply because the language never supported ways to avoid them originally; other languages are finally being enhanced to address things like this, but Delphi remains stuck in the Dark Ages when it comes to useful language enhancements. Like the use of strings on case statements that practically every language in use today supports, just not Delphi. 

 

Compilers are supposed to make the work of programmers EASIER. I don't subscribe to notions that "we don't do that because it's not in the 'spirit' of Pascal" or whatever. That's just BS. It's like saying you'll never put an electric starter on your cars because it's just not historically accurate with original car designs. So you have to get out and crank a lever in the front of the car to get the engine started.

 

I don't know about anybody else, but I'm sick and tired of hearing off-the-cuff comments from managers and VPs who make technology usage decisions saying that Delphi old and stale so they can't wait to replace their code with "a more modern language". At the place I started working at in mid-January, the CTO cornered me one day after I'd been here about 3 weeks and said, "So how much work do you think it would take to replace all of the Delphi and MySQL with C# and SQL Server?"  Why is this such a pervasive and recurring question everywhere I've worked for a decade?

 

There may be something heart-warming about the fact that Delphi can compile code written in 1995, but it's keeping management teams at corporations of all sizes from embracing Delphi because there are plenty of language enhancements in C, C++, C#, Python, Ruby ... you name it, that are not in Delphi, and from all indications will never be. That gives the clear impression that Delphi is old, stale, stodgy, and is something nobody wants to use because it has no support fo the latest language features that other languages have.

 

For 12 years now, I've worked at one place after another where my job was to keep a bunch of legacy Delphi code alive until they can replace it with "something more modern". That's THEIR words, not mine! And I have absolutely no defense for it. They use the Pro version of Delphi, not Ent or Arch, because they don't use any of the other stuff bundled with the bigger packages. Just the language and a few 3rd-party component libs (mostly free stuff).

 

There are other tools that implement Pascal variants that are almost totally compatible with Delphi, and add plenty of new language features that are on-par with contemporary languages. These prove it can be done elegantly and cleanly. But the compiler builders need the motivation to do it.

 

If the folks who own Delphi ever hope to get it mainstream again, they need to bring the language into the 21st century and add features that most other contemporary languages have had for a while now. But when the topic comes up, all we ever hear is crickets. "Oh, but look at all the work we've done with our latest Interbase enhancements!" There's lots and lots of work being done enhancing stuff that hardly anybody uses. But enhancements to the core product are nowhere to be found.

Edited by David Schwartz
  • Like 5

Share this post


Link to post
Posted (edited)
11 minutes ago, David Schwartz said:

Compilers are supposed to make the work of programmers EASIER. I don't subscribe to notions that "we don't do that because it's not in the 'spirit' of Pascal" or whatever. That's just BS.

YES, exactly that!

 

However many Delphi developers have a troubled past where often "new" things turned out to be broken, caused problems or were simply not thought through entirely and just slapped onto existing things like duck tape. Like using attributes like [ref] in addition to the existing keyword const just because of the fear to introduce new keywords or introducing inline variables (that had many bugs) without the entire tooling understanding them and stopping to work. So many people are in the mindset of "don't touch it so you can't break it" and "fix the existing bugs before adding new broken stuff"

Edited by Stefan Glienke
  • Like 2

Share this post


Link to post
1 minute ago, Stefan Glienke said:

YES, exactly that!

 

However many Delphi developers have a troubled past where often "new" things turned out to be broken, caused problems or were simply not thought through entirely and just slapped onto existing things like duck tape (such as using attributes like [ref] in addition to the existing keyword const just because of the fear to introduce new keywords). So many people are in the mindset of "don't touch it so you can't break it" and "fix the existing bugs before adding new broken stuff"

As if that has never happened with anything Microsoft ever published ...

Share this post


Link to post
Just now, David Schwartz said:

As if that has never happened with anything Microsoft ever published ...

VS is also not perfect but their compiler and language design is rock solid - yes, if you look into C# communties there are also people complaining that stuff is not C#-ish and that but the number of times where the C# compiler just craps itself, kills the entire IDE or simply produces completely wrong code is like several orders of magnitudes less than with Delphi.

  • Thanks 1

Share this post


Link to post
27 minutes ago, Stefan Glienke said:

"fix the existing bugs before adding new broken stuff"

Actually I don't need new broken stuff at all - regardless of existing bugs being fixed or not.

  • Like 1
  • Sad 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×