[lazarus] Order of destruction in TCustomListBox

[Mattias Gaertner]

On Mon, 15 Dec 2003 09:01:47 +0100  Micha Nelissen <micha at neli.hopto.org>
wrote:

> Mattias Gaertner wrote:
> 
> > On Sun, 14 Dec 2003 15:09:48 +0100  Micha Nelissen
> > <micha at neli.hopto.org> wrote:
> >><output>
> >>CB.SomeFunc call
> >>Constructor
> >></output>
> >>
> >>Which is not logical, IMHO.
> > 
> > 
> > It is just a matter of definition. Although it would be interesting how
> > you imagine a more logical alternative.
> 
> The definition is: the object is only 'defined', if it's constructor has 
> run completely. Something along those lines is used by C++. After each 
> constructor run, and only then, are the overriden function pointers 
> written to the VMT. Personally, I think this is more logical, although 
> maybe it's a matter of personal taste.

I got the feeling, Micha is talking about general OOP, while the answers are
about implementation details in FPC/Delphi. I think, the real problem is
that there are different definitions of OOP.

About your definition: "the object is only 'defined', if it's constructor
has run completely."

No one will argue about this. Because it does not say a word about inherited
constructors. I guess, you mean something like this:

"every class level of an object is only 'defined', if the constructor of
this level has run completely."

This is the OO view, looking from the outside. You call the constructor to
create and initialize an object (aka an instance of a class). 
Looking from the inside, no constructor is atomic. Creation and
initialization are splittet and inherited constructors are parts of the
initialization process. So, you can only say: "the object initialization is
completed, when it's constructor has run completely."
Inheritance means enhancing a class by adding and changing. The changing is
important here. An inherited object is not just the old class plus some
features. It can behave differently. 
The constructor is no exception. The constructor is overriden and uses the
inherited constructor, because this is the whole point of inheritance: to
save code and to create "is a" relationships. 

So, if you say, that an inherited constructor should create a complete
defined ancestor class (and only this), then you have extended the OO model
by some limits, and this way you can easily make Delphi's/FPC's object
pascal illogical. 

Of course you can also argue: Using another OO definition than FPC and
saying FPC's OOP is not logical is illogical.


Mattias