I’m doing some work to upgrade old-style objects including class operators/management operators and better construction.

It’s natural to do ClassType.Constructor which translates to a “new” statement but not sure about what can be done for destructors. Maybe call the destructor directly like “o^.destroy” which translates to a “dispose” statement, or an implicit .free method? I assume this needs to be put behind a mode switch also.

Any ideas?

type
  TMyObject = object
    constructor Create;
    destructor Destroy;
  end;
constructor TMyObject.Create;
begin
end;
destructor TMyObject.Destroy;
begin
end;
var
  o: TMyObjectPtr;
begin
  // new(o, Create);
  o := TMyObject.Create;
  // what to do here???
  o^.destroy;
  // implicit free method?
  o^.free;
end.

Regards,
Ryan Joseph

Ryan Joseph schrieb am Fr., 24. Mai 2019,
01:20:

I’m doing some work to upgrade old-style objects including class operators/management operators and better construction.

Please don't. They're legacy types (even though we don't consider them obsolete) and geared towards the TP behavior and compatibility.

Regards,
Sven

On May 24, 2019, at 4:49 AM, Sven Barth via fpc-devel wrote: Please don't. They're legacy types (even though we don't consider them obsolete) and geared towards the TP behavior and compatibility.

{ resending this again because the old message got blocked }

I thought FPC was trying to keep them alive? Objects are still the only way to do inheritance for records but they lack operator overloads. The syntax for new/dispose certainly feels legacy but that’s not as important as the class operators.

Regards,
Ryan Joseph

Ryan Joseph schrieb am So., 26. Mai 2019,
17:05:

Keeping them alive is not the same as developing new syntaxes for them (and for objects that *would* be a new syntax). Also we fix bugs for them which Delphi does not do.

Regards,
Sven

On May 26, 2019, at 2:58 PM, Sven Barth via fpc-devel wrote: Keeping them alive is not the same as developing new syntaxes for them (and for objects that *would* be a new syntax). Also we fix bugs for them which Delphi does not do.

Can we at least do operators overloads for them then? It’s such a trivial change and makes it possible to use inheritance for records (I can do this in C++,C#,Swift which is very nice). Specifically I was trying to refactor some code and using subclasses for vectors would be really nice but without operator overloads it’s not possible.

Also, since we’re not getting ARC classes it looks like, management operators for objects would make it possible to use a base class for “boxing” managed classes.

Regards,
Ryan Joseph

Do records support inheritance in next FPC? 3.0.4 doesn't seem to allow that and this is the main reason i use objects when i need value types.

Actually, what are the differences between records and objects that make it impossible for records to get objects' features or objects to get records' features so there is no difference between the two and one become alias for the other?

I often want value types and find myself having to choose between the two depending on the features i need. It'd be very nice if both had the same features or at least one became a full superset of the other.

No, only objects. Objects don’t have operator overloads though so they can’t be used in some cases. Of course records could support inheritance but I think that’s even more contentious (and instrusive to the compiler) than adding operator overloads to objects.

Records don’t have a VMT table and overriding but otherwise they’re the same afaik (constructors don’t work the same also). Operator overloads simply aren’t enabled for objects because apparently they’re a legacy syntax but as you pointed out they’re still useful. Being able to use subclassing for TVec2 -> TVec3 -> TVec4 objects would be really useful. I hope the compiler team reconsiders this.

Regards,
Ryan Joseph

Ryan Joseph wrote

Records don’t have a VMT table and overriding but otherwise they’re the same afaik (constructors don’t work the same also). Operator overloads simply aren’t enabled for objects because apparently they’re a legacy syntax but as you pointed out they’re still useful.

Are you sure about the operator overloads? I'm pretty sure I've used them on objects since FPC 1.0.x (even before that) and they've always worked fine. They are also used by some of the PTCPas example programs, which are shipped with FPC and also work fine. I even tested it again with a trivial example. Here it is: It works with FPC 3.0.4 and almost certainly FPC trunk as well:

type
   TMyObject = object
   end;
operator + (a, b: TMyObject) res: TMyObject;
begin
   Writeln('Plus operator! yeah!');
end;
var
   a, b, c: TMyObject;
begin
   c := a + b;
end.

So, what's with all this FUD surrounding operator overloading not working with objects? Did you even test it, before screaming "legacy!"? :)

Nikolay

Nikolay Nikolov schrieb am Do., 30. Mai 2019, 00:52:

So, what's with all this FUD surrounding operator overloading not working with objects? Did you even test it, before screaming "legacy!"? :)

He's talking about operator overloads that are members of the object like what was introduced for records and not about global operators. And yes, there's a small, but important difference: generics can only pick up the global ones if the unit containing the operator overloads was used inside the unit the generic was declared in (not specialized in).

Regards,
Sven

Thanks for the clarification. I didn't know about this difference and thought it was just different syntax (namely Delphi copying C++ and C# instead of following FPC, which had operator overloading long before Delphi).

Nikolay

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

Regards,
Ryan Joseph

Make that 100% :-)

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)

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.

Michael.

Very well. That means objects are our only option.

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

On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt wrote: (same for properties, BTW)

Just noticed this. Yes, why don’t records have properties? Seems like an omission.

Regards,
Ryan Joseph

Yes.

I imagine it is indeed trivial.

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.

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.

Records do. Objects not.

Michael.

On Jun 10, 2019, at 1:20 PM, Michael Van Canneyt wrote: Records do. Objects not.

Ooops forget the mode switch. :) I’m seeing objects have properties. Are you sure? Maybe they got added recently.

Regards,
Ryan Joseph

On Jun 10, 2019, at 1:19 PM, Michael Van Canneyt wrote: I don't think that for classes this should be allowed. Sven and Florian already explained the reasons for this in detail.

Yes but that was in regards to binary operators which would have memory management issues. The operators I listed return boolean so there’s risk. It would be pretty inconsistent however.

I don’t think this is possible. Just did little test and the size of “result” is always the size of the base class. Does this work?

Also FPC doesn’t have something “self” but for the class level so you need to cast the return value. Btw adding “ClassSelf” is something I’ve wanted for a while, so I can reference the class type within the class declaration.

type
  PBase = ^TBase;
  TBase = object
    x: integer;
    constructor Initialize;
    class function Create: PBase; static;
  end;
class function TBase.Create: PBase;
begin
  writeln('create: ', sizeof(result));
  new(result, Initialize);
end;
constructor TBase.Initialize;
begin
  writeln('create tfoo')
end;
type
  PChild = ^TChild;
  TChild = object (TBase)
    y: string;
  end;
var
  c: PBase;
begin
  c := TChild.Create;
end.

Regards,
Ryan Joseph

Well, at the time I used objects, they didn't exist.

But I haven't used objects in a long time, so maybe they got added quite some time ago. I will check and update the docs when needed.

Michael.

Ryan Joseph schrieb am Mo., 10. Juni 2019, 19:56:

Also FPC doesn’t have something “self” but for the class level so you need to cast the return value. Btw adding “ClassSelf” is something I’ve wanted for a while, so I can reference the class type within the class declaration.

What are you talking about here?

Regards,
Sven

Like this. I would prefer there being a “ClassSelf” type or something which acted as TSelf.

type
	TRecord = record
		public type
			TSelf = TRecord;
		public
			class operator + (left: TSelf; right: integer): TSelf;
			class operator + (left: TSelf; right: integer): TSelf;
			class operator - (left: TSelf; right: integer): TSelf;
			class operator * (left: TSelf; right: integer): TSelf;
			class operator / (left: TSelf; right: integer): TSelf;
			class operator ** (left: TSelf; right: integer): TSelf;
			class operator div (left: TSelf; right: integer): TSelf;
			class operator mod (left: TSelf; right: integer): TSelf;

Regards,
Ryan Joseph

PM Ryan Joseph wrote

I don’t think this is possible. Just did little test and the size of “result” is always the size of the base class. Does this work?

Result in your example is the size of a *pointer* in all cases, which is fine / exactly what you'd expect it to be.

On Jun 10, 2019, at 3:25 PM, Ben Grasset wrote: Result in your example is the size of a pointer in all cases, which is fine / exactly what you'd expect it to be.

Sorry, if I dereference the size is still of TBase. I don’t think “result" is actually changing depending on the class type. This may have something to do with the way new works though. How can we fix this?

type
  PBase = ^TBase;
  TBase = object
    constructor Initialize;
    class function Create: PBase; static;
  end;
class function TBase.Create: PBase;
begin
  new(result, Initialize);
  writeln('create: ', sizeof(result^));
end;
constructor TBase.Initialize;
begin
  writeln('create tfoo')
end;
type
  PChild = ^TChild;
  TChild = object (TBase)
    y: string;
  end;
var
  c: PChild;
begin
  c := PChild(TChild.Create);

Regards,
Ryan Joseph

Ryan Joseph schrieb am Mo., 10. Juni 2019, 20:31:

Ehm... You are aware that you can simply use TRecord here?

Regards,
Sven

Ryan Joseph schrieb am Mo., 10. Juni 2019, 21:31:

Of course the dereferentiation of PBase while always have the size of TBase. That's the point of a pointer. You need to add a static Create method to each subclass if you want to use that concept. And no kind of TClassSelf or whatever will help you there as you'd need virtual class functions for that and objects don't support those just as they don't support a "class of" kind of type. There's a reason why classes are superior in nearly all cases after all.

Regards,
Sven

On Jun 10, 2019, at 4:04 PM, Sven Barth via fpc-devel wrote: Ehm... You are aware that you can simply use TRecord here?

Yes but it’s lots of redundancy. It’s nice to have a type that says “the type of the structure”, the same as what “self” basically means but at the class level (compile time). TObject has ClassType but a compile time construct would be a nice companion.

Regards,
Ryan Joseph

On Jun 10, 2019, at 4:07 PM, Sven Barth via fpc-devel wrote: Of course the dereferentiation of PBase while always have the size of TBase. That's the point of a pointer. You need to add a static Create method to each subclass if you want to use that concept. And no kind of TClassSelf or whatever will help you there as you'd need virtual class functions for that and objects don't support those just as they don't support a "class of" kind of type. There's a reason why classes are superior in nearly all cases after all.

Got it. That aside the operators are the important thing anyways.

Another question. I’m not sure it’s possible but I did try to add management operators to objects and found that if a initialize operator was declared in a unit which was precompiled and then inherited from an object in another unit which declared another initialize operators, the initialize operator would be called twice.

The issue is that the operator is compiled into some other code which always gets called when the object is used as a var type. Is there any work around to that? The options I’m aware of are:

1) don’t allow management operators in objects (that would be very unfortunate indeed).
2) don’t allow subclasses to redeclare a management operator (that seems ok since the operator can call a virtual method from the base class).
3) allow overriding of operators. I don’t think that would be make sense or perhaps even possible.

Regards,
Ryan Joseph

{ resending this, I think it got lost during the server move since I’m not seeing it in the archives }

Another question. I’m not sure it’s possible but I did try to add management operators to objects and found that if a initialize operator was declared in a unit which was precompiled and then inherited from an object in another unit which declared another initialize operators, the initialize operator would be called twice.

The issue is that the operator is compiled into some other code which always gets called when the object is used as a var type. Is there any work around to that? The options I’m aware of are:

1) don’t allow management operators in objects (that would be very unfortunate indeed).
2) don’t allow subclasses to redeclare a management operator (that seems ok since the operator can call a virtual method from the base class).
3) allow overriding of operators. I don’t think that would be make sense or perhaps even possible.

Regards,
Ryan Joseph

On Jun 12, 2019, at 9:39 AM, Ryan Joseph wrote: { resending this, I think it got lost during the server move since I’m not seeing it in the archives }

{ I think the server is back up so I’m resending this for the 3rd time to see if it gets through. }

Another question. I’m not sure it’s possible but I did try to add management operators to objects and found that if a initialize operator was declared in a unit which was precompiled and then inherited from an object in another unit which declared another initialize operators, the initialize operator would be called twice.

The issue is that the operator is compiled into some other code which always gets called when the object is used as a var type. Is there any work around to that? The options I’m aware of are:

1) don’t allow management operators in objects (that would be very unfortunate indeed).
2) don’t allow subclasses to redeclare a management operator (that seems ok since the operator can call a virtual method from the base class).
3) allow overriding of operators. I don’t think that would be make sense or perhaps even possible.

Regards,
Ryan Joseph

Ryan Joseph requested that I reply to this to show that it's in the mailing list.  Hopefully the technical problems can be resolved!

Gareth aka. Kit

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Hi,

J. Gareth Moreton wrote

Ryan Joseph requested that I reply to this to show that it's in the mailing list.  Hopefully the technical problems can be resolved!

There was an issue affecting GMail users, and GMail's SMTP servers over IPv6. This has been resolved by now. (By disabling IPv6, which is somehow always the easiest solution for IPv6 problems...)

Charlie

Thanks, I’m seeing this now. I can’t find the thread in the archives though but I see my new thread with the same name appear in the archives. My email client may be messing with me also because I don’t see it yet. Sorry for the noise if you guys are seeing everything.

On Jun 15, 2019, at 11:35 AM, J. Gareth Moreton wrote: Ryan Joseph requested that I reply to this to show that it's in the mailing list. Hopefully the technical problems can be resolved!

Regards,
Ryan Joseph

Charlie, I’m still not seeing my own messages posted even though I’m seeing others and I can confirm via the archives my messages are being received. Is this a problem with the server or my email client? If you happened to notice I was having problems with my SMTP server so I switched to Gmail, which was working for a week or so until the server went down.

Thanks.

Regards,
Ryan Joseph

Ryan Joseph wrote

Charlie, I’m still not seeing my own messages posted

if gmail can determine that a message coming in from a list is one you sent, it does not pass it on back to you... there's no way to turn this off that i've found... they want you to use their interface to read conversations and your sent message is included in there slotted in where it should be...

Am 16.06.2019 um 17:43 schrieb

I see my own messages both on the GMail Android app as well as Thunderbird.

Regards,
Sven

that's weird... i pull my gmail via pop3 in to my tbird and never get any of my list posts back... i'm on 10+ lists... some with this account and others with my gmail... the gmail account never sends back my messages when i pop them...