Delphi adopted FPC?

[x2nie]

Its now turn into another topic.
whatever...

Never ran into a task where I'd need to have an advanced record, operator overloading or type helpers.

I have other experience with advanced records and operators overloading. These features allow to make custom types nearly (nearly because not all needed operators can be overloaded) first class citizens, what in one's part make code more simple, readable and humane.

Well, I think the idea of record operator and record.constructor is come from C#?
Whatever, I dislike that record features. Better if I declare it as object rather than record.
So I can distinct exactly and easily between record's member and object's properties.
Maybe I am too old when I still love the syntaxs that are used in TurboPascal : no record's constructor nor record operator .

Any task could be implemented without having them using regular pascal language.

Then wherefore advanced records, operators overloading, type helpers and other Delphi-features? Go to Delphi 7 dialect! Hardcore and pain. Pain but hardcore.

That's what I'm doing. No pain, predictable and cross compiler friendly code. Consumed by all delphi and fpc versions. Compatible and robust.

Never ran into a task where I'd need to have an advanced record, operator overloading or type helpers.

Agree with "No pain, predictable".
I also never require the "advanced record". I feel that's not good pascal, at least is not my expected pascal dialect.
IFAIK, in C# all things is class/object. there is no real "record" there. When this limitation bring to pascal code, it is bad by design.
So, when I need to compare between a record, I still don't require record.operator, I would be happier if I could declare Object / Class because property+constructor is Object/Class (eventually if I am using C#).

[taazz]

Agree with "No pain, predictable".
I also never require the "advanced record". I feel that's not good pascal, at least is not my expected pascal dialect.

Personally I wanted something along those lines since the 90s. I like to be able to declare my own data types and how they should handle them selfs in the basic arithmetic operations so I can write that reads for example

Code: [Select]

Type
  TMyVector = record
    X, Y, Z : single;
  end;
...
function Test :TMyVector;
var
  Local1, Local2 : TMyVector;
begin
  InitVector(local1,1);//set all fields to 1;
  InitVector(loca2,3);//set all fields to 3;
  Result := ((Local1+local2)*Local1)/(local1*Local2);
end;

As you can see its a lot easier to write than

Code: [Select]

Type
  TMyVector = record
    X, Y, Z : single;
  end;
...
function Test :TMyVector;
var
  Local1, Local2 : TMyVector;
begin
  InitVector(local1,1);//set all fields to 1;
  InitVector(loca2,3);//set all fields to 3;
  Result := Vector_Divide(Vector_Multiply(Vector_Add(Local1,Local2), local1),Vector_Multiply(Local1,local2));
end;

So although it is restricted to records only it is a huge step forward to the correct direction (personally I can't think of any non record case, except strings and code pages, that I could use this)

[Leledumbo]

I look at unassigned bugs in bugtracker. More than 480 always.

Many factors: Uncertainty, waiting for feedback, no one knows the solution, silently solved. 480 is small enough, considering the project size.

[skalogryz]

..
As you can see its a lot easier to write than
..

It is indeed much easier to read.

But I'd suggest even uglier version:

Code: [Select]

Type
  TMyVector = record
    X, Y, Z : single;
  end;
...
function Test :TMyVector;
var
  Local1, Local2 : TMyVector;
  t1, t2: TMyVector;
begin
  InitVector(local1,1);//set all fields to 1;
  InitVector(loca2,3);//set all fields to 3;
  Vector_Add(Local1,Local2, t1); // the last parameter is a "var"
  Vector_Multiply(t1, local1, t2);
  Vector_Multiply(Local1,Local2, t1);
  Vector_Divide(t2, t1, Result);
end;

For a technical reason, explicit passing a variable by reference is slightly faster than getting it from the function result.
The compiler allocates the result size on stack and then copies it a variable accepting the result. In case of one big expression, it might do some unnecessary copies/allocations.
Of course, the compiler could (should? does?) optimize the call to make them exactly efficient and use the accepting variable as a reference.

Assembler would reveal the truth. But it doesn't seem to do it with all optimizations off.

[x2nie]

Agree with "No pain, predictable".
I also never require the "advanced record". I feel that's not good pascal, at least is not my expected pascal dialect.

Personally I wanted something along those lines since the 90s. I like to be able to declare my own data types and how they should handle them selfs in the basic arithmetic operations so I can write that reads for example

Code: [Select]

Type
  TMyVector = record
    X, Y, Z : single;
  end;
...
...
  Result := ((Local1+local2)*Local1)/(local1*Local2);

As you can see its a lot easier to write than

Code: [Select]

  Result := Vector_Divide(Vector_Multiply(Vector_Add(Local1,Local2), local1),Vector_Multiply(Local1,local2));
...

So although it is restricted to records only it is a huge step forward to the correct direction (personally I can't think of any non record case, except strings and code pages, that I could use this)

Agree with you that the second option is easier for our eye to understand; though if I may, I would not sacrifice the original pascal concept.
I mean record should be in different structure than object/structure;
I mean record should NOT have method,constructor,property. I expect record should only have member and nothing else.


It's not because the problem in syntax taste only (which is cosmetic), I assume there would affect in performance.
So, I expect to keep record as record, and if I need property/method I can declare the data in Object / Class manner.


Anyway, tazz... I respect to your personal opinion. That's not bad, that's good too.
I just didn't yet able to feel comfort with record that act as class like this:

Code: [Select]

PRectInteger = ^TRectInteger;
  TRectInteger = record
  private
    function GetWidth: Integer;
    function GetHeight: Integer;
  public
    {$IFNDEF FPC}
    constructor Create(X1, Y1, X2, Y2: Integer); overload;
    constructor Create(Rect: TRectInteger); overload;
    {$ENDIF}


    class operator Equal(const Lhs, Rhs: TRectInteger): Boolean;
    class operator NotEqual(const Lhs, Rhs: TRectInteger): Boolean;
    class operator Add(const Lhs, Rhs: TRectInteger): TRectInteger;
    class operator Subtract(const Lhs, Rhs: TRectInteger): TRectInteger;
    class function Zero: TRectInteger; {$IFDEF SUPPORTS_INLINE} inline; {$ENDIF} static;


    procedure Normalize;
    function Clip(var Rect: TRectInteger): Boolean;
    function IsValid: Boolean;


    property Width: Integer read GetWidth;
    property Height: Integer read GetHeight;


  case Integer of
    0: (X1, Y1, X2, Y2: Integer);
    1: (Values: array [0..3] of Integer);
    2: (Point1, Point2: TPointInteger);
    3: (Points: array [0..1] of TPointInteger);
  end;

[taazz]

you can have those too, for those low level hardware communications, when needed so nothing lost so far. I guess a simple operator definition with out the need for a class/extended record would make more sense in non OOP world something along the lines of

Code: [Select]

operate Equal(Var1,Var2:TMyVector):boolean;
begin
  //code
end;
operate Equal(Var1,Var2:TMyVector):boolean;
begin
  //code
end;
operator Add(Var1,Var2:TMyVector):TMyVector;
begin
end;
....
could do the trick I guess as long as they are in the same unit as the type definition everything should be the same.

[FPK]

I look at unassigned bugs in bugtracker. More than 480 always.

And how much patches did you contribute to resolve them?

[skalogryz]

Never ran into a task where I'd need to have ... or type helpers.

..and right after I've said that, I found a task for them.
Extending a class public API (including adding some properties) without changing the base class.

Kudos to type helpers and other sugars! 

[kazalex]

Maybe I am too old when I still love the syntaxs that are used in TurboPascal : no record's constructor nor record operator .

Maybe. But maybe you very long ago not look into source of Delphi RTL for a examples of using modern features (little yet). Do it now. I have 20 year Pascal background (I am not too old?) and i love his new features.

And how much patches did you contribute to resolve them?

None. Or you think that fact of using open source project obliges me to contribute code for him? But may be you think that i criticize the developers of FPC? No, i talk why FPC cannot replace modern Delphi and only it. It's objective opinion because i not have strong affection for Delphi but for Pascal has (yes i like FPC and Lazarus), and i'm not blind fanatic (and not retrograde also. sugar-sugar-sugar) ready to disclaim facts.

[x2nie]

Maybe I am too old when I still love the syntaxs that are used in TurboPascal : no record's constructor nor record operator .

Maybe. But maybe you very long ago not look into source of Delphi RTL for a examples of using modern features (little yet). Do it now. I have 20 year Pascal background (I am not too old?) and i love his new features.

I have 15 years alive with pascal. Still using Delphi 5,6,7 (because my company projects depends on huge of proprietary packages). I did hard eliminate them with handmade components/package.


Hi kazalex, you cut my paragraph and pin up the separate sentence of it which is come to different meaning.
I can say that you are too busy to read to get the correct purpose of what actually I want to say?


Generally, I have no problem with Modern syntax introduced and supported by both FCL + Delphi...
so, of course I am fine with Delphi RTL + FCL RTL !
However, personally I always avoid to use "record that act as class", I mean when we need properties/methods/constructor why not using "object" or "class" rather than ambiguous "record" (though FCL/Delphi recognize it as well).
IMHO, record is not a class nor an object. In my brain: record can be used just like string : no constructor required for instantiate a string.
While a record has properties etc.,  what is the result of : SizeOf( TMyRecordRect ) ?
The answer of this question is very important for me,


I love the classic approach of record that is only member allowed.
This idea exactly come to me from TVirtualTreeView that allocate array of record to gain lightning speed, instead of using TCollection+TCollectionItem, nor using TList which are slower when are allocated in huge amount.
----------------------------


Back to original topic, is Delphi adopted FPC?

• The non-secret fact is : Lazarus adopting Delphi. It is done by FPC supported inside. Whatever I can do with Delphi, I can do with Lazarus, and in some cases was in better way.
• The secret fact is : Delphi adopted C# OOP approach such by allowing "record" to has such constructor and properties (which is not original pascal OOP aproach).
• Eventually seem as fact : FPC seem to adopting whatever Delphi could do, including that new record's behavior.

FPC/Lazarus tries to be Delphi compat, Delphi tries to adopt/clobber/be compat with FPC...is this a perverted never ending "snake biting its tail" loop?Okay, ac(h)cording a violin with a guitar won't push the music out of the Art!But my opinion is = Delphi and FPC/Laz should stop running each after the other and begin a separate life

@sam707: no way! don't let it stop. The winner is their customer. Competition is good for quality.
There was a day that Turbo Pascal was single player, leaving Quick Pascal, Intel Pascal and other competitor away. What then happened ?
Delphi was single player in "Visual Pascal", then company turn into .NET in Delphi 8, dropping away their very best support of Win32API.
The fact: Delphi require competitor in the same base. If they don't meet any, they turn to make somebody else to be their competitor in another competition (compete with Visual Studio / C#)

The love hate relationship of freepascal and delphi is required at this stage of development. Hopefully in a few more years lazarus and lcl will have enough customers to stand to its own feet.

Fully agree.
Lazarus probably just need to spread more, make more advertising, fund-rise, whatever to bold the state that FPC+Lazarus is not worse than Delphi.

[x2nie]

you can have those too, for those low level hardware communications, when needed so nothing lost so far. I guess a simple operator definition with out the need for a class/extended record would make more sense in non OOP world something along the lines of

Code: [Select]

operate Equal(Var1,Var2:TMyVector):boolean;
begin
  //code
end;
operate Equal(Var1,Var2:TMyVector):boolean;
begin
  //code
end;
operator Add(Var1,Var2:TMyVector):TMyVector;
begin
end;
....
could do the trick I guess as long as they are in the same unit as the type definition everything should be the same.

Do you mean this :

Code: [Select]

function Equal(Var1,Var2:TMyVector):boolean;
begin 
//code
end;

function NotEqual(Var1,Var2:TMyVector):boolean;
begin 
//code
end;
function Add(Var1,Var2:TMyVector):TMyVector;
begin


end;
instead?


I can't found any page while googling with "operate pascal delphi freepascal" keyword. 

[Leledumbo]

I can't found any page while googling with "operate pascal delphi freepascal" keyword. 

"operator overloading (delphi OR freepascal)", no quotes, will do

[taazz]

instead?
I can't found any page while googling with "operate pascal delphi freepascal" keyword. 

true that is why it will do a good new definer instead of function. As it is now there is no support for non OO way to overload operators so it was just an idea.

[kazalex]

However, personally I always avoid to use "record that act as class", I mean when we need properties/methods/constructor why not using "object" or "class" rather than ambiguous "record" (though FCL/Delphi recognize it as well).

For a start... Object types are supported for backward compatibility only (with controversial implementation of OOP in Turbo Pascal). Their use is not recommended. (c) Delphi Help. Forget theirs.

Class types is always requiring works with dynamic memory, that not always justifiably. Class types is always requiring manual controls of life time (except interfaces, contained in smart containers etc.).
Simple pseudocode with advanced records:

Code: [Select]

Type

 TArray = Class

  Private

   Type

    TRange = Record

     Procedure Init(AParent : TArray; ALow, AHigh : Integer);

     Function GetEnumerator : TRangeEnumerator; // ALow to AHigh for Parent;

    End;

  Public

   Function Range(ALow, AHigh : Integer) : TRange;

 End;

Var

 a : TArray;
 s : String;

Begin

  For s In a.Range() Do;

End;
If TRange will be a class type then we need mechanism of control his life-time and have absolutely superfluous operations with dynamic memory.

IMHO, record is not a class nor an object. In my brain: record can be used just like string : no constructor required for instantiate a string.

Advanced records no requires constructors and can be used just  like string:

Code: [Select]

Var

 a : XmlRpcArray; // record
 v : XmlRpcValue; // record

 Begin

  SetLength(a, 100);
  // or
  a.Length := 100;
  // or
  a.Initialize(100);
  // or
  a.Initialize(100, typeString);
  // or
  a.Initialize([1, 'two', pi, XmlRpcArray.Create(1000)]);

  WriteLn(v.ValueTypeName); // 'Unassigned';

  for v in a do
   writeln(v.ValueTypeName); // 'Int32, String, Double, Array'

 End;

While a record has properties etc.,  what is the result of : SizeOf( TMyRecordRect ) ?
The answer of this question is very important for me.

Why generally must arise this question? Why not "what is the result of TMyClass.InstanceSize?" You are not surprised when using Variant, because he is TVarData record?

[snorkel]

don't be naive - FPC cannot replace modern Delphi.

sure it can, I don't use Delphi anymore and use Laz+FPC for everything now.  So it replaced it for me at least :-)