However, `private' means unit/modules wide visibility. -- One could discuss how useful it is, but since we follow (mostly) BP's object model, that's just the way it is.
That's just what I was wondering about; you see, the descendant that is trying to `overwrite' a field is declared in a different module. I had thought `private' would allow me to do what I'm trying to do.
I think it would be strange if such an "overloaded" field is allowed when in different modules, but suddenly becomes invalid when moved.
I think it's strange that `overloading/overwriting' a private field is invalid, when I'm doing so outside the parent's module. ;)
You said, and I quote, ```private' means unit/modules wide visibility'; why don't we keep it that way? IMHO, there's not much lossage in sticking with the letter of above rule.
If someone needs a procedure/function accessing a private field in an object, it's easy enough to stick in that object's module, again, IMHO. Also, don't you think it's more natural having private fields that're private through and through? That is, they're private not only with regards to access, but also in definitions of descendants?
Just my two cents. And, yes, I know we're discussing how useful the Borland OOP paradigm is. :D