* * *

Author Topic: management operators for advanced records now also in Delphi 10.3.  (Read 805 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 7149
Interesting... Our estranged cousin introduced a feature we already have.
http://blog.marcocantu.com/blog/2018-november-custom-managed-records-delphi.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+marcocantublog+%28marcocantu.blog%29

Pity they felt the need to have a differing syntax. As usual.
http://wiki.freepascal.org/management_operators

Reading the comments is funny: most have no clue why this is such a powerful feature.
« Last Edit: November 08, 2018, 07:18:06 am by Thaddy »
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

Akira1364

  • Sr. Member
  • ****
  • Posts: 381
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #1 on: November 08, 2018, 07:33:39 am »
most have no clue why this is such a powerful feature.

At least two people there seemed to realize they're not as useful as they could be without some variation on "default field" functionality though (which in FPC as of recently there's now two fully working separate implementations of by different people, yet still seemingly no movement on actually anything getting into the compiler...)

Thaddy

  • Hero Member
  • *****
  • Posts: 7149
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #2 on: November 08, 2018, 08:13:17 am »
The current implementation - in fpc - is afaik by the same people. Sven and Maciej. It is just that Maciej pursued the default operator in newpascal. There's no code in fpc trunk (maybe yet) to support that. So a little nuance should be in place. I like the feature though, even without the additional default support. (that's why I put it in the wiki). NewPascal is not making any visible progress atm, which is a bit disappointing. Anyway it is a powerful feature (deep vs shallow copy comes to mind) and I use it more and more.
BTW there is a usually interesting, but pending, comment from Allen Bauer on that blog. So those who are interested should have a look in a few days.
« Last Edit: November 08, 2018, 08:23:06 am by Thaddy »
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

440bx

  • Sr. Member
  • ****
  • Posts: 337
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #3 on: November 08, 2018, 09:04:24 am »
whenever Embarcadero adds a feature to Delphi, I wonder how far the FPC development team will go to remain Delphi compatible.

I am purposely going to avoid being specific but, there are some really terrible ideas implemented in Delphi and there are obviously more coming... it seems that a lot of programmers are afflicted with binary diabetes, they just cannot get enough syntactic sugar.






Thaddy

  • Hero Member
  • *****
  • Posts: 7149
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #4 on: November 08, 2018, 09:17:14 am »
I actually broadly agree with you. <surprised?  :P >
The Delphi "feature" for inlined variables fits the bill. Horrible.< >:D>
But this is no syntactic sugar but an actual improvement on the language.
« Last Edit: November 08, 2018, 09:19:01 am by Thaddy »
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

440bx

  • Sr. Member
  • ****
  • Posts: 337
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #5 on: November 08, 2018, 09:19:40 am »
I actually broadly agree with you. <surprised?  :P >
yes, I am.  I had no idea you actually had some common sense.  What a nice surprise.  :)

creaothceann

  • Jr. Member
  • **
  • Posts: 73
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #6 on: November 08, 2018, 04:52:05 pm »
The Delphi "feature" for inlined variables fits the bill. Horrible.

Why?

Thaddy

  • Hero Member
  • *****
  • Posts: 7149
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #7 on: November 08, 2018, 05:30:00 pm »
separation of declaration and use is an essential feature of the pascal language.
allowing inline variable declaration is fun for lazy individual programmers but hell for their colleagues that have to debug such code.
In a team of programmers this feature should be disallowed (as the C equivalent is in most big shops: try to find it in the linux core sourcecode ) because it causes more harm than it does good,
Looks great..... but has The Jack.
« Last Edit: November 08, 2018, 05:33:43 pm by Thaddy »
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

Handoko

  • Hero Member
  • *****
  • Posts: 2642
  • My goal: build my own game engine using Lazarus
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #8 on: November 08, 2018, 05:45:25 pm »
I'm more interested with the terrible ideas implemented in Delphi (or maybe FPC) as mentioned by @440bx and @Thaddy. Can you please list more items that you think they're 'ugly'? I think it has educational value. Sorry of being off topic, or should I start a new thread?

Note:
Although I have 'Hero Member' status above my avatar picture but because I'm an autodidact hobbyist programmer, I missed many 'formal' knowledge about programming.

440bx

  • Sr. Member
  • ****
  • Posts: 337
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #9 on: November 08, 2018, 10:08:24 pm »
I'm more interested with the terrible ideas implemented in Delphi (or maybe FPC) as mentioned by @440bx and @Thaddy. Can you please list more items that you think they're 'ugly'? I think it has educational value. Sorry of being off topic, or should I start a new thread?

Note:
Although I have 'Hero Member' status above my avatar picture but because I'm an autodidact hobbyist programmer, I missed many 'formal' knowledge about programming.
Even though I really have little interest in discussing language design (the subject has a tendency to lead to rather unproductive discussions),  I do feel I owe at least one example.  Therefore here is one, likely the first Borland design atrocity that made it into the Pascal language, is the so called "writeable constants".

In a declaration such as:
Code: Pascal  [Select]
  1. const
  2.   // AONTS = ArrayOfNullTerminatedStrings
  3.   AONTS : array[0..1] of pchar = ('first char array', 'second char array');
  4.  

The pointers in the array aren't constant but the compiler has to treat them as if they were at compile time, however at runtime, it treats them as variables.
At runtime you can assign a new pointer to AONTS[0] and AONTS[1] and the pointer, while it needs to be a pchar, it isn't required to point to a constant string, it can point to a buffer whose contents may/can change at anytime.  This in turn causes a problem, if the programmer attempts to change the original string an exception will occur since the pointer is pointing to an initialized constant in a non-writeable segment in the exe but, if the pointer is changed to point to some buffer (and if the buffer is large enough) then the operation will succeed. 

In C++ (where they implemented it correctly), the pointers are variables and/but, those variables are [must be] pointers to constants.   The compiler will NOT accept an element of that array being assigned a pointer which is not a pointer to a null terminated character constant (as it should.)  Therefore _all_ attempts to modify the target of the pointer will result in an exception (as it should.)

Writeable constants = a terrible idea.  The reason they implemented them is because allowing the construct
Code: Pascal  [Select]
  1. var
  2.   SomeVar : integer = 10;
would have required changes in the code generator.  Specifically, if the above construct had been allowed then, if it had been used to declare a local variable (instead of a global variable) then the compiler would have had to generate code to initialize the local variable, since they didn't want to enhance the code generator to do that, they came up with "writeable constants".  That way, they created a construct which cannot be used for local variables thus eliminating the need to generate code and breaking language symmetry.  _bad_, really _bad_.

I have mixed feelings providing only one example when there are actually quite a few but, I know where providing such a list leads and I am not interested in getting there, since there is no chance that any of these "deficiencies" will be addressed, much less corrected.

Here is a complete example that shows one of the many problems created by writeable constants
Code: Pascal  [Select]
  1. {$MODE OBJFPC                      }
  2.  
  3. program PointersToConstantCharArrays;
  4.  
  5. const
  6.   constchar   = 'a character constant array';
  7.  
  8.   aconstarray : array[0..1] of pchar = ('first', 'second');
  9.  
  10. type
  11.   rec = record
  12.     intfield : integer;
  13.     charfield : pchar;
  14.   end;
  15.  
  16. const
  17.   // this works because there is no array of pointers to the character array
  18.   // i.e, constchar is itself the pointer to the character array.
  19.  
  20.   recconst : rec = (intfield : 0; charfield : constchar);
  21.  
  22. const
  23.   // this does NOT work
  24.  
  25.   // it should NOT force the use of the @ operator, it won't compile without it
  26.   // and with it, the output is wrong.  This results in charfield holding a
  27.   // pointer to a pointer to characters instead of a pointer to characters.
  28.   // IOW, charfield is a ppchar instead of, what it should be, a pchar.
  29.  
  30.   recconst2 : array[0..1] of rec
  31.     = (
  32.        (intfield : 0; charfield : @aconstarray[0]),
  33.        (intfield : 0; charfield : @aconstarray[1])
  34.       );
  35.  
  36. var
  37.   AnArray : array[0..31] of char;
  38.  
  39. begin
  40.   writeln(recconst.charfield);
  41.  
  42.   // the following two statements output garbage because charfield is a pointer
  43.   // to a pointer to characters.  charfield is NOT a pointer to characters which
  44.   // is what writeln expects.
  45.  
  46.   writeln(recconst2[0].charfield);    // outputs garbage
  47.   writeln(recconst2[1].charfield);
  48.  
  49.   AnArray[0] := 'h';   AnArray[1] := 'e';   AnArray[2] := 'l';
  50.   AnArray[3] := 'l';   AnArray[4] := 'o';   AnArray[5] := #0;
  51.  
  52.   // this assignment should not be possible
  53.  
  54.   aconstarray[0] := AnArray;    // AnArray isn't a pointer to a string of
  55.                                 // character constants.  The compiler should NOT
  56.                                 // allow this but, it has to.
  57.   writeln(aconstarray[0]);
  58.  
  59.   // it is possible to write to aconstarray[0][0]
  60.  
  61.   aconstarray[0][0] := 'f';
  62.   writeln(aconstarray[0]);
  63.  
  64.   // but the same thing on [1][0] will result in a SIGDEV
  65.  
  66.   aconstarray[1][0] := #0;
  67. end.
  68.  
The ambiguity (and inconsistency) is clearly visible between aconstarray[0] and aconstarray[1].  The compiler should _not_ have allowed aconstarray[0] to be a pointer to a non constant.








Akira1364

  • Sr. Member
  • ****
  • Posts: 381
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #10 on: November 09, 2018, 04:11:54 am »
The current implementation - in fpc - is afaik by the same people. Sven and Maciej.

There's another (completely different) more recent one, that's just based on the normal FPC codebase (no NewPascal stuff) by someone named Ryan Joseph that was posted to the mailing list. This is his github:
https://github.com/genericptr/freepascal/tree/defaultprops

It actually does quite a bit more than Maciej's version did, as you can see here:
https://github.com/genericptr/freepascal/tree/defaultprops/tests/defaultprops
« Last Edit: November 09, 2018, 04:21:26 am by Akira1364 »

Thaddy

  • Hero Member
  • *****
  • Posts: 7149
Re: management operators for advanced records now also in Delphi 10.3.
« Reply #11 on: November 09, 2018, 04:56:55 am »
Actually, if it is just about smart pointers, once the default keyword works reliable my own smartpointer (first published on this forum) based on interfaces will also work transparently (now you have to access value), That is even easier. I recently added an explicit operator improvement so you can do this:
Code: Pascal  [Select]
  1. {$ifdef fpc}{$mode delphi}{$warn 5090 off}{$endif}
  2. uses
  3.   classes,smartptrs;
  4. var
  5.   L:Auto<TStringlist>;
  6. begin  
  7.   // auto create and auto free a stringlist
  8.   // default property does not work (yet)
  9.   // but hardcasts do work now.
  10.   with TStringlist(L) do
  11.   begin
  12.     Add('Testme');
  13.     writeln(Count);
  14.     Add('foo');
  15.     Add('foo2');
  16.     Add('Foobar');
  17.     Writeln(Count);  
  18.     writeln(Text);
  19.   end;
  20. end.
« Last Edit: November 09, 2018, 05:14:22 am by Thaddy »
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus