What is the difference between the new ADVANCED RECORD and the old OBJECT?

[mse]

One often has different records with a common header.
Here base objects which will be inherited by specialized objects are convenient. For many cases classes (TObject descendants) have too much not needed overhead so "old style" objects fit well.

Yeah, or just read the general header and a separate header for the extensions. These (doutbful!) cornercases are not really motivations IMHO to keep a complete object model running.

Did you ever made a compiler for example? OK, a compiler is maybe a cornercase but it's lists are full of header-paydata structures, often even multi level.

In MSElang "object" and "class" are almost the same. "class" instances are always allocated on heap and provide implicit pointer dereference. "object" is  instantiated as stack- or global-variable or on heap if the "object" has a constructor and a destructor, see
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects
MSElang objects and classes can have variant parts, classes can inherit from objects.

If I would start over, that's probably what I would do, with one exception. I would leave objects pure structures, so no VMT (and thus probably no virtual).

One of the things I hate most about TP objects, is that you can't immediately see if it is a pure record or an object.

In MSElang the [virtual] object/class header attachment defines it. There is no VMT without [virtual].

[marcov]

Did you ever made a compiler for example? OK, a compiler is maybe a cornercase but it's lists are full of header-paydata structures, often even multi level.

I'm currently working on the chm compiler. While not a compiler in the classic sense, it has a lot of binary internal structures, including B+trees. I have dabbled with compilers, interpreters and expression evaluators in the past.

In MSElang the [virtual] object/class header attachment defines it. There is no VMT without [virtual].

(and the second annoyance about TP object btw is the manual pointer declaration for objects. I find it annoying even in C++ where you don't have to constantly declare it. The common case should be easy, and shouldn't be hampered by a corner case.)

If we ever align advanced records to class in the same way, something like that could solve that yes. Though I would lean towards simply forbidding vmt beyond class level.

[PascalDragon]

To mention another important difference between object and record that also was (aside from Delphi compatibility) the main reason to add methods to records in the first place: advanced records can contain operator overloads as part of them (in comparison to global operator overloads) that then can be used inside a generic declaration.

[mse]

(and the second annoyance about TP object btw is the manual pointer declaration for objects.

I don't understand. What do you mean with "manual pointer declaration for objects"?

If we ever align advanced records to class in the same way, something like that could solve that yes. Though I would lean towards simply forbidding vmt beyond class level.

Why not universal and orthogonal? Also classes without VMT have it's use, MSElang supports it.

To mention another important difference between object and record that also was (aside from Delphi compatibility) the main reason to add methods to records in the first place: advanced records can contain operator overloads as part of them

In MSElang operator overloading is also done in objects/classes with the [operator=] method attachment.
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects#operator

[ASerge]

First there were record, procedures and functions.
Next, with the emergence of OOP, there were objects.
Next, Borland has introduced classes in which there are additional opportunities. And to force everyone to switch to a new way of declaration, a objects was sign as deprecated.
Later, when it was necessary to merge fields and methods again, it was already inconvenient to revive objects declared as deprecated. And decided to expand records.
And, accordingly, all the new features have tried to do only for records, skipping the implementation for objects, so that they correspond to the previously established policy. And either intentionally made mistakes in the support of old objects, or rather greatly inflated random errors to convince not to use objects.
If we compare records and objects and classes in in FPC now, then

Feature	Record	Object	Class
Encapsulation (combining data and methods + hiding visibility)	Yes	Yes	Yes
Inheritance	No	Yes	Yes
Class constrcutor and destrutor	Yes	Yes	Yes
Polymorphism (virtual methods)	No	Yes	Yes
Memory allocation	Stack	Stack	Heap
Operator overload (global)	Yes	Yes	Yes
Operator overload (in type only)	Yes	No	No
Type helpers	Yes	No	Yes
Virtual constructors, class reference	No	No	Yes

It should be noted some inconvenience of objects.
If it declares virtual methods, its size increases for storage of VMT (records not containing VMT, size not changed, classes always has VMT, size not changed).
To make virtual methods work, you must define a constructor and call it (the constructor is required for classes).

[howardpc]

A further difference between advanced records and objects/classes is the possibility of advanced records having variant parts (with or without methods).
As far as I can see the keywords "procedure" and "constructor" can be used interchangeably in advanced records. Is there in fact any difference between them in this case?

[avra]

If we compare records and objects and classes in in FPC now, then

This nice comparison table should end up in a wiki...

[440bx]

If we compare records and objects and classes in in FPC now, then

This nice comparison table should end up in a wiki...

I concur with the above.  Very nicely done Serge.

[Thaddy]

@ASerge
Don't forget management operators for records. (3.2+)
Also note that advanced records do have a VMT if these are used.

[avra]

Don't forget management operators for records. (3.2+)
Also note that advanced records do have a VMT if these are used.

Thanks for the update, Thaddy

[JernejL]

So, nowadays, why should I choose advanced records instead of object type?

Record routines in FPC inline better than object methods (from my experience)
Memory alignment control for structures (plus very fast read & write, you can just write and read it to Tstream)
Bit packed records are possible too, when dealing with specific limitations or special projects.
Easier allocation for some very fast purposes (array of records can be allocated with just a simple setlength call)
Faster (no RTL overhead).
No constructors needed in variables, just declare & call routines directly on it.
 

[Awkward]

Jernel, objects are like records can be used without constructors, with easy allocation, memory alignment. When records will have inheritance (like in Oberon for example), MAYBE objects will be much less usable. But now objects still have their own area.

[PascalDragon]

@ASerge
Don't forget management operators for records. (3.2+)
Also note that advanced records do have a VMT if these are used.

But unlike for objects that is not part of the record "instance", but only part of the Init RTTI metadata, thus per type.

[Thaddy]

@ASerge
Don't forget management operators for records. (3.2+)
Also note that advanced records do have a VMT if these are used.

But unlike for objects that is not part of the record "instance", but only part of the Init RTTI metadata, thus per type.

Thanks for adding the difference...

[ASerge]

Feature	Record	Object	Class
Encapsulation (combining data and methods + hiding visibility)	Yes	Yes	Yes
Inheritance	No	Yes	Yes
Class constrcutor and destrutor	Yes	Yes	Yes
Polymorphism (virtual methods)	No	Yes	Yes
Memory allocation	Stack	Stack	Heap
Operator overload (global)	Yes	Yes	Yes
Operator overload (in type only)	Yes	No	No
Type helpers	Yes	No	Yes
Virtual constructors, class reference	No	No	Yes
Variant part (case) as c++ union	Yes	No	No
Bitpacked (really packing)	Yes	No	No

Added a variant part and bitpacked. Thanks @howardpc and @JernejL.