[fpc-pascal] Managed record questions

[Ryan Joseph]

> On Mar 9, 2018, at 3:55 PM, Michael Van Canneyt <michael at freepascal.org> wrote:
> 
> Hence my proposal to 'clean this up’.

A good idea if they would be used. If objects had a couple minor things I personally could replace some records in certain parts of code and get real benefits. Someone on the compiler team would actually have to do this work though so it’s a cost/benefit analysis.

> 
>> 3) I suppose it never existed but “override” missing is pretty strange. Historical I guess.
> 
> You don't need "overrid"e for objects, it is automatical.

Another mystery of why classes added this then? I personally like it since it’s an indication of an overriding and gives some compiler warnings.

> 
>> 4) Move() on an object copies memory like a record (as a record does, so this is good). Does that mean they laid out in memory just like records?
> 
> Yes, although I believe there is a hidden VMT field.

Not sure how they look in memory but that code works so I guess they’re safe to use as records. I could be wrong though and cause nasty bugs using them as pure data structors (like passing to C functions!)

type
	TDataObject = object
		v: array[0..2] of integer;
	end;

procedure TestObjectCopy; 
var
	obj: TDataObject;
	data: array[0..2] of integer;
	i: integer;
begin
	for i := 0 to 2 do
		obj.v[i] := 100 + (100 * i);
		
	Move(obj, data, sizeof(TDataObject));
	for i := 0 to 2 do
		writeln(data[i]);
end;

> 
>> 
>> So why do we have advanced records then if objects do more than records? The overhead of a virtual method table? Records have a better/cleaner syntax for operator overloads than even classes but what else?
> 
> Simple: Delphi compatibility.
> 
> You can probably find some of my cries of despair on the mailing lists,
> lamenting the fact that they decided to invent something new when they had
> it all along since many decades :(

I wonder how much code is shared between objects and records in the compiler. It’s really just a syntax difference if all they really wanted was Delphi compatibility. It’s a real shame to because the time could have been spent making objects more unified with classes.

> 
>> 
>> Unlike C++ the object’s destructor was not called when it went out of scope but if it did that they would be an interesting replacement for classes in some cases. The compiler knows how to cleanup stack variables but does it call any virtual method on objects in this situation?
> 
> I do not think so.

Maciej, could you add your management operators to objects? Maybe the code for records/objects overlaps in places and it could be possible, although, the operator overload syntax for classes is not the same records (which is really a shame in itself) so perhaps not.

If you could add that then objects would have built-in ARC and since you can actually subclass them the implementation would be hidden away (instead of the messy generic wrapper we need to use with records).


Regards,
	Ryan Joseph