[fpc-devel] Object upgrades

[Ryan Joseph]

> On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt <michael at freepascal.org> wrote:
> 
>> 
>> So where do we stand on this?  I have a patch to make it possible allow
>> operator overloads that are members of objects but I hear that objects are
>> legacy types.  I disagree of course and claim they are the only way to get
>> inheritance for records since I’m 99% certain FPC is never going to allow
>> record inheritance.
> 
> Make that 100% :-)

Very well. That means objects are our only option.

> 
>> Personally I have an immediate use for objects but I
>> need them to have operator overloads as members of the object for generics
>> support (this isn’t possible with the stand-alone function operator
>> overloads).
>> 
>> Could we at least make this upgrade to objects with a mode switch?
> 
> If it is under a mode switch (advancedobjects, similar to advancedrecords), I see no harm in this. I would even say it is logical to add it. I always felt strange that records have it but objects not. (same for properties, BTW)

Great, one person on my side. It’s a totally trivial change also so that’s good news.

My original idea was to make these available for classes also but Sven shot that idea down. Is that the final position? There are at least the following operators which could be safely added to classes.

class operator not (left: TSelf): boolean;
class operator <> (left: TSelf; right: TRight): boolean;
class operator < (left: TSelf; right: TRight): boolean;
class operator > (left: TSelf; right: TRight): boolean;
class operator <= (left: TSelf; right: TRight): boolean;
class operator >= (left: TSelf; right: TRight): boolean;
class operator = (left: TSelf; right: TRight): boolean;
class operator >< (left: TSelf; right: TRight): boolean;
class operator in (left: TSelf; right: TRight): boolean;

If that’s rejected then I guess we’re left with “advancedobjects” mode switch?


> 
> Your other proposal of changing the memory use is of a different caliber,
> because it fundamentally changes the way objects are used. The objections against that proposal remain intact.

What happened is that classes introduced this idea in FPC that TClassName.Create is syntax for allocation (in the trunk even dynamic arrays use this syntax now) so I wanted to extend that to the legacy “new” function which just looks wrong now as a result. Is there anything we could do to make “new” more modern look like classes?

Regards,
	Ryan Joseph