[fpc-devel] Object upgrades

[Michael Van Canneyt]

On Mon, 10 Jun 2019, Ryan Joseph wrote:

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

Yes.

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

I imagine it is indeed trivial.

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

I don't think that for classes this should be allowed. 
Sven and Florian already explained the reasons for this in detail.

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

Yes.

>> 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?

First of all, I don't think you need to make objects "look" more like classes.

There is nothing wrong with alerting people that they're using a different
kind of animal when using objects. I for one want to see at a single glance
what code does. So seeing "New" instead of "Create" alerts me to the fact that I am
dealing with objects. I consider this a plus, and if they start sharing more
functionality, this plus becomes more important.

So IMO there is no need to change the compiler for this.
Just add a static function that returns a new instance, which you can call 
"create" if this pleases your sense of beauty or symmetry.

Michael.