On Thu, 3 Jun 2010, Graeme Geldenhuys wrote:

On 3 June 2010 20:38, Michael Van Canneyt wrote:

Because Borland decided otherwise.

Actually, there is a good reason: some components create internal components
they own, and which they don't want to have streamed.
The 'GetChildren' allows you to control what gets streamed and what not.

Well, isn't that what the 'stored' specifier could be used for too, to
know if a property should be stored or not.

No, because there may not be a property. You can perfectly have a child
component without a property to access it.

It just looks like a
rather odd implementation (broken by default) for something that is so
easily accomplished with a recursive procedure. All the required
functionality (ComponentCount, Components[]) is already in place.

Once more, you need a way to distinguish between owned components
that must be streamed, and components that must not be streamed.
The 'Stored' modifier is not suitable because there may not be
a property to access the component. Plenty of examples around for that.

In LCL the owner is always the form. Otherwise the form variables
would not work.

I know that, and the same think applies to VCL. But again, I don't see
why Borland had to do that. Like fpGUI proves, it's not even required
to have Owner and Parent. fpGUI can easily remove Parent and just use
Owner and work perfectly. At the moment in fpGUI, Parent is just for
convenience to VCL/LCL developers - it's just an alias for Owner.

Personally, I think that this is mixing 2 concepts:

Owner/Owned is a matter of lifetime and memory management of objects.
Parent/Child is a visual relationship.

They are separate concepts, and Borland decided to reflect this in the streaming system. (apart from the need to be able to exclude children from
being streamed).

I suppose there was a reason why they did this.
I once had a discussion about it with a Borland employee, and the way he made a point of it makes me believe there is a reason for it. We simply don't
know it.

Michael.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to