I'm no expert so these answers may be a bit off, but I figure any help is nice during US business hours...
> Are there somewhere more or less pedagogic examples of class code? I've never found any. I've learned largely by studying (and occasionally fixing) fpgui code. > *self* > Do i need to explicitely name self as param? Depends on context? I use 'self' for the following: - if I am inside a 'with' context, and there is another data type with an identical field name, I'll reference self.field_name - even without a 'with' context I'll sometimes use it to make things easier to read - to call a procedure which takes a class as a parameter. A particularly common example would be a constructor that requires a parameter which will be its owner: e.g. within a method of a 'window' object I might call Tscrollbar.create (self); so that the window is the owner of the scrollbar... and the scrollbar can look at the window to get its size. > 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? I'm not sure, but self.method and self.field have always worked fine for me. Never tried to put a caret into the syntax. > *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...). Do you mean, are you required to *write* a destructor? No, but you can. I use them to destroy child objects. 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. > Isn't it garbage collected when dereferenced? No, classes are not automatically deallocated when dereferenced. They are pointers, and there may be several references to them (and they are not reference-counted) so there is no automatic deallocation. You need to call Free. > *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. I'm not sure I understand your question but maybe this is your answer: a_type = class; b_type = class; a_type = class b : b_type; end; b_type = class a : a_type; end; > 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). You mean ... as opposed to a non-class procedure, which could simply be defined in the implementation section of a unit, without any mention in the interface? I don't know all the proper terminology, but my best guess is this: when the compiler creates the framework for the class, it needs to have everything available. Once it gets to the implementation section, it's too late to be adding more methods into that framework, or VMT, or whatever the thing is called. Hope this was helpful and not terribly incorrect! Cheers, David. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
