language updates in 10.4?

[David Heffernan 2345]

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. 

[Sherlock 663]

13 hours ago, Stefan Glienke said:

https://en.wikipedia.org/wiki/Hyperbole

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

[Stefan Glienke 2002]

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 March 12, 2020 by Stefan Glienke

[Guest]

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 March 14, 2020 by Guest

[Lars Fosdal 1791]

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?

[Uwe Raabe 2057]

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.

[Sherlock 663]

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.

[Uwe Raabe 2057]

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.

[Guest]

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 March 16, 2020 by Guest

[Rollo62 536]

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.

 

[Kryvich 165]

@TomDevOps There have been some corner cases, but I think most of them have already been fixed (for ex. https://quality.embarcadero.com/browse/RSP-23417) or will be fixed in 10.4.

 

 

[Kryvich 165]

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.

[Markus Kinzler 174]

We have to wait and see...

[vfbb 285]

@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;

 

[Kryvich 165]

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;

 

[Dalija Prasnikar 1396]

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

[Lars Fosdal 1791]

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

[Dalija Prasnikar 1396]

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. 

[Leif Uneus 43]

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.

[Stefan Glienke 2002]

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.

[Darian Miller 361]

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"

 

 

[Darian Miller 361]

Added a quick blog post on inline variables: https://www.ideasawakened.com/post/newly-discovered-hidden-benefits-of-inline-variables-in-delphi

[Rollo62 536]

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