Jump to content
David Schwartz

language updates in 10.4?

Recommended Posts

1 hour ago, David Schwartz said:

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

Spend some time looking at the development process and quality over in C# and .net land, and then see if you honestly can regard Emba's process and quality even remotely in the same ball park. 

  • Like 2

Share this post


Link to post
Posted (edited)
1 hour ago, Sherlock said:

So you trust inline variables to work flawlessly and use them wherever you like? You trust the TParallel lib?

I would like to but I don't (and not because of FUD but because I know of the bugs myself) - do I need to say anything more? Ask around in other languages if people in general trust their compilers and standard runtime libraries or not.

Edited by Stefan Glienke

Share this post


Link to post
Guest
Posted (edited)
On 3/11/2020 at 6:21 PM, David Schwartz said:

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?

 

I got exactly the same from my managers! We are replacing Delphi stuff with C# and we will not go with Delphi 10.4, we will keep 10.3.3 and uninstall it when we finish migration (should be this year or beginning of next). It is a shame that this language cannot catch-up with rest of the mainstream languages.

 

 

On 3/12/2020 at 8:11 AM, Sherlock said:

So you trust inline variables to work flawlessly and use them wherever you like? You trust the TParallel lib?

Well... I'm this idiot who trust inline variables (use it everywhere) and use TParallel library, surprisingly, in both cases I have no issues so far 😉 

Edited by Guest

Share this post


Link to post
On 3/12/2020 at 9:54 AM, Stefan Glienke said:

I would like to but I don't (and not because of FUD but because I know of the bugs myself) 

Have anyone done an article on the current pitfalls of inline variables?

Share this post


Link to post
7 hours ago, TomDevOps said:

Well... I'm this idiot who trust inline variables (use it everywhere) and use TParallel library, surprisingly, in both cases I have no issues so far

I have to confess that regarding the PPL I am the same idiot as you. On the other hand, it is like with all tools: You have to know how to use them and especially know where you have to be careful. As much as I love OTL I am often not in the position to make the decision for it.

Share this post


Link to post

I use TParallel as well, but not to the extent some folks do. And I'm not sitting by meticulously counting CPU cycles either. But I do avoid inline variables - well avoid is a strong word...I ignore them.

Share this post


Link to post
1 hour ago, Sherlock said:

But I do avoid inline variables

Me too, but just because I still have to maintain a couple of projects with older Delphi versions. While it is possible to handle that with conditional defines, that means double work for inline variables.

Share this post


Link to post
Guest
Posted (edited)

I have only two projects (2-3 years old), one for Windows and one for iOS/Android, and I use inline variables like crazy all over the place, it is so C# like and it is very convenient 😉 

 

It works for me but I guess this is because use cases? What is wrong with inline variables in Delphi?

Edited by Guest

Share this post


Link to post
8 minutes ago, TomDevOps said:

I use inline variables like crazy all over the place, ...

Thanks for testing so deeply ☝️

 

9 minutes ago, TomDevOps said:

What is wrong with inline variables in Delphi?

Nothing, I love inline variables too.

I just would wait until its really stable for production, maybe I look at it in Rx10.4.

 

Share this post


Link to post

So how you like a syntax Embarcadero finally choose for initialization / finalization of the custom managed records?

type
  TMyRecord = record
    Value: Integer;
    class operator Initialize (out Dest: TMyRecord);
    class operator Finalize(var Dest: TMyRecord);
    class operator Assign (var Dest: TMyRecord; const [ref] Src: TMyRecord);
  end;

Early in 2018 Marco showed a slightly different syntax.

I personally would prefer something like

type
  TMyRecord = record
    Value: Integer;
    operator Initialize;
    operator Finalize;
    operator Assign(const [ref] Src: TMyRecord);
  end;

Then Dest would be replaced by Self.

Share this post


Link to post

@Kryvich If they implement record inheritance, now or in the future, I would prefer it to be more like an object:

type
  TMyRecord = record(TParentRecord)
    Value: Integer;
    constructor Create; override;
    destructor Destroy; override;
    procedure Assign (const [ref] Src: TMyRecord); override;
  end;

In this case the record would be like a "class" arc in all platforms, like strings and dynamic arrays, but with support for operators and having the exact size of their fields. It would be incredible.

 

But if they don't implement inheritance, syntax better resemble the record operators that already exist, as the embaradero proposed:

type
  TMyRecord = record
    Value: Integer;
    class operator Initialize (out Dest: TMyRecord);
    class operator Finalize(var Dest: TMyRecord);
    class operator Assign (var Dest: TMyRecord; const [ref] Src: TMyRecord);
  end;

 

Share this post


Link to post

Well I would prefer the short form for other record operators too:

   typeName = record
     operator conversionOp: resultType;
     operator unaryOp: resultType;
     operator comparisonOp(b: type): Boolean;
     operator binaryOp(b: type): resultType;
   end;

 

Share this post


Link to post
On 3/14/2020 at 8:56 AM, Lars Fosdal said:

Have anyone done an article on the current pitfalls of inline variables?

There have been few bugs around inline variables, but for using inline variables in day to day code, probably the greatest problem was non functional code completion and code navigation. They would also break Error Insight, but that thing is all kinds of broken, so having one more way to break it is not critical. Besides, Error Insight itself is not critical feature.

 

On the other hand, one permanent pitfall lies in inline variables combined with type inference and reference counted classes as explained in my blog post https://dalijap.blogspot.com/2019/03/inline-variables-type-inference-and.html

  • Like 2

Share this post


Link to post

I've also seen compile time issues where you must specify the type T of the iterator for a TArray<T>.  

  • Like 1

Share this post


Link to post
8 minutes ago, Lars Fosdal said:

I've also seen compile time issues where you must specify the type T of the iterator for a TArray<T>.  

I cannot say I had such encounters. In every place I tried to use them, main problem was killing code completion and navigation (or maintaining backward compatibility)

 

I also used them (actually, type inference that comes along) in some places where my old library code was no longer compilable in Rio - mostly around changes in generic lists and Items. 

Share this post


Link to post
2 hours ago, Dalija Prasnikar said:

There have been few bugs around inline variables, but for using inline variables in day to day code, probably the greatest problem was non functional code completion and code navigation.

The greatest problem with inline variable declarations, are backward compatibility.

I don't see any benefit, except for some logical clarifications.

Share this post


Link to post
2 minutes ago, Leif Uneus said:

The greatest problem with inline variable declarations, are backward compatibility.

I don't see any benefit, except for some logical clarifications.

That is only an issue for library authors that need to target a range of past versions which is the vast minority of Delphi users.

Most migrate to a new version, start using that and never have to run their code through previous versions.

 

Type inference for inline variables is a really nice thing - no need to explicitly decare the type just to tell the compiler (yes, if you name your variable properly the type is irrelevant for understanding the code, ask programmers from other languages that have this feature for a long time). Also often enough you have to add units to a uses clause just to declare a variable of a type that is the return of a method of some other type being used - with type inference that becomes unnecessary.

  • Like 4
  • Thanks 1

Share this post


Link to post
57 minutes ago, Stefan Glienke said:

Also often enough you have to add units to a uses clause just to declare a variable of a type that is the return of a method of some other type being used - with type inference that becomes unnecessary.

 

Now that is definitely worthwhile... I didn't realize that benefit until I read your comment, then re-read it, then said "no way", then created some test code knowing that it wouldn't work, and then said "cool"

 

 

Share this post


Link to post

@Darian Miller

Thanks for the nice article, I also miss inline variables since C/C++.

I'm only afraid of the many hidden traps the first implementation might step into, under all strange real life conditions .

So probably I will try to use them only carefully step by step, not massively, in the first versions.

It's a nice feature, but also I can still live without it, as I did so many years.

 

More important to me is, can the debugger handle this, do I get strange error messages.

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

×