[fpc-pascal] question about class

[Andrew Hall]

>> Do i need to explicitely name self as param?
self is a reserved keyword which represents the reference to the object of context (much the same as using "result" in a function) - it is understood by the compiler and does not need to be specified.

>> Is self actually a pointer? If yes, do I need to treat as such, or is this
>> magically handled by the language? Eg self^.prop or self.prop?
Self is a pointer.  Delphi (and FPC which it is based upon) treats the dereference ^ as implicit.

>> *destructor*
>> Is a destructor required? What is it supposed to do? Deallocation? (but then
>> self disappears in the middle of a method it is the target of...).
A destructor is only required if your object has its own private structures to finalise/dispose/etc.  If you do not need your own destructor, the virtual destructor in TObject will suffice.  

> Or, do you mean, do you need to *call* a destructor? Yes, you do. You should 
> call "Free" rather than "Destroy". I don't recall why.
Free is used because it is a static method and can be safely called against a nil object reference (Destroy is virtual, and so will raise an access violation when the application attempts to access the object's VMT).  Free simply checks whether self is nil...   "if self <> nil then Destroy"

>> Isn't it garbage collected when dereferenced?
As David says, objects are not reference counted.  You must use interfaces (which are usually implemented via TInterfacedObject) for that feature.  Note that interfaces are not "garbage collected", per se - they are immediately released when the reference count hits zero.  This is in contrast to other languages where objects are cleared by a "garbage collection" process triggered either intermittently, or when other conditions are met (eg. low memory).  

>> *type mutual recursion*
>> One func method returns an object of another type (actualy a record, but I
>> guess it does not make any difference). But this record object holds a pointer
>> to an object of the first type... Similar issue with a param of another
>> method. There was no issue in the non-class version of the same code, since
>> pseudo-methods (and their params and return values) did not need to be
>> pre-declared.
Where there are cross references to classes in the same section, one or both can be declared TMyClass = class; as long as the full declaration appears later in the same section.  This allows two classes to reference each other.  This does not work with records, however.  Note - that generic pointers, or using base class references (like TObject) in the declaration can also be useful approaches to issues around access to class types (which can be cast in the implementation "fMyTObject as TMySpecificObject".

>> By the way: why do we need to pre-declare methods, since they are bound to
>> their type anyway by their name prefixes? (I mean so-called "qualified names"
>> of the form type.methodName).
The only part of a unit visible to another unit is the interface section.  Everything other units might touch must be declared there (same as non-class procedures and functions).  Visibility of fields and methods in a class is controlled using "published/public/protected/public"

Regards Andrew.