[fpc-pascal] class & object

[Michael Van Canneyt]

On Mon, 10 May 2010, spir ☣ wrote:

> Hello,
>
>
> Below two quotes from the ref manual:
>
> http://www.freepascal.org/docs-html/ref/refch6.html#x67-750006
> << In the Delphi approach to Object Oriented Programming, everything revolves around the concept of ’Classes’. A class can be seen as a pointer to an object, or a pointer to a record, with methods associated with it.
> The difference between objects and classes is mainly that an object is allocated on the stack, as an ordinary record would be, and that classes are always allocated on the heap. In the following example:
> Var
>  A : TSomeObject; // an Object
>  B : TSomeClass;  // a Class
> The main difference is that the variable A will take up as much space on the stack as the size of the object (TSomeObject). The variable B, on the other hand, will always take just the size of a pointer on the stack. The actual class data is on the heap.
> From this, a second difference follows: a class must always be initialized through its constructor, whereas for an object, this is not necessary. Calling the constructor allocates the necessary memory on the heap for the class instance data. >>
>
> http://www.freepascal.org/docs-html/ref/refse32.html#x69-770006.2
> << Classes must be created using one of their constructors (there can be multiple constructors). Remember that a class is a pointer to an object on the heap. When a variable of some class is declared, the compiler just allocates room for this pointer, not the entire object. The constructor of a class returns a pointer to an initialized instance of the object on the heap. So, to initialize an instance of some class, one would do the following :
>  ClassVar := ClassType.ConstructorName;
> The extended syntax of new and dispose can not be used to instantiate and destroy class instances. That construct is reserved for use with objects only. Calling the constructor will provoke a call to getmem, to allocate enough space to hold the class instance data. After that, the constuctor’s code is executed. The constructor has a pointer to its data, in Self. >>
>
>
> I'm rather confused when reading this.
>
> First, "class" is used at several places where I would expect "instance". The actual construction of a _class_ (or object type), meaning the data structure in memory that represents the class itself, is certainly transparent for the programmer. If I'm wrong, then I I'm really lost ;-) If I'm right, then the start of the second quote actually means, using my words:
> << Instances must be created using one of the constructors defined on the class (there can be multiple constructors). Remember that an instance... >>
> And the second sentence of the first quote may start with:
> << An instance can be seen as a pointer to an object,... >>
> In the second paragraph, each occurrence of "class" should be replaced by "class instance". Etc.

I will look at this.

>
> Second, theses texts seem to imply that classes only have drawbacks, compared to object types ;-) 
> The reference does not compare the two models further, I guess; so why bother with a heavier system? 
> Why did Delphi creators design such a complicated framework, while they already had the TP way?
> Is there a document somewhere describing the traits, advantages & drawbacks, and possibly the typical 
> use cases, of both systems? Also, are there any data about compared performance using records+procs+funcs 
> vs. object OO vs. class OO?

Practice shows that most instances are on the heap, so Borland has 'formalized' this. 
All in all, I think it is a step ahead. Combined with the virtual
constructors and class pointers, this is a very powerful mechanism.

(note that in their .NET version, they re-introduced objects as 'Records with methods')

> Also, I don't understand why, in the case of class, the extended syntax of new() cannot allocate the 
> object on the heap. Isn't this precisely what a pointer is intended for?

Because you need the correct constructor, and constructors can be virtual
and are therefor not necessarily known at compile-time.

> Also, what's the actual 
> difference with object, why does it work? Does this, and the fact that it is stored on the stack,
> mean that an instance of an object type is _not_ adressed via a pointer?

Yes. You don't need a pointer in that case.

> Or does the reference manual actually speak of classes and object types --not of instances? 
> If yes, why should we care (they're few and small, since written by hand...)?

I will see if the manual can be improved in this.

Michael.