Thanks for clarifying. That would be useful for more simple things.
You're welcome. Advanced records are a good choice when 1. you don't need polymorphism, 2. you don't need them to inherit from something and 3. there is no need for something else (object or class) to inherit from them (since an advanced record cannot be inherited from.) An advanced record is basically a normal record that in addition to listing fields also has a list of functions and procedures that have access (can use) the fields as well as a set of visibility specifiers and possibly a list of properties but, functionally, it pretty much is the same as a record that is restricted to be used by the list of functions, procedures, properties it declares in its body. Other than the syntactic sugar advanced records provide (properties being the "sweetest" part), anything an advanced record can do can be done with a plain record.
Do objects inherit advanced records?
No but, _conceptually_ an "object" (not a class) can be thought of as the combination of an advanced record and a virtual method table (a VMT, whose existence is what enables inheritance and polymorphism.)
A class is very similar to an object in that it also has a VMT but, unlike an object, a class is always allocated on the heap whereas, both, an object or an advanced record can be allocated _either_ on the heap or, unlike classes, on the stack too.
The fact that a class is always allocated on the heap is what allows the compiler to hide that a class is a pointer (it dereferences the pointer automatically, therefore the programmer doesn't have to type "^" to access the class' fields.)
Besides not allowing virtual methods and inheritance, do the advanced records take less resources than a comparable object with same structure ?
Yes, because an advanced record does _not_ have a VMT, therefore it always uses less memory than an "equivalent" object or class. That said, in most cases, the additional memory that is taken by the VMT isn't something that is worth losing any sleep over.
Objects were a bit of a problem when stacks were limited to 64K. Initially, a class was pretty much an object that was always allocated on the heap (which did not have the 64K limit) and, because it was always allocated on the heap, the compiler could hide the fact that the class variable is a pointer by doing automatic dereferencing. As time went by, classes gained features while objects were left behind (I believe Delphi has deprecated objects but, I could be wrong about that.)
Given that in today's machine, there really is no limit to how large a stack can be, memory is no longer an issue for the old objects.
HTH.