Why can't I have a private field in a child that has the same name as a private field in an ancestor? I don't think there's going to be much difficulty determining which private field is referenced; UIM, it'll be similar to how `virtual' methods are traced.
This is what I get while trying to do this:
TException.eph:86: error: cannot overwrite data field `ObjectStructure' of parent object TException.eph:85: error: duplicate field `ObjectStructure'
Using build 20040516 (binary distro).
I'm not sure how other compilers handle this, but, IMVHO, this behavior is desirable.
Neil Santos a écrit:
Why can't I have a private field in a child that has the same name as a private field in an ancestor? I don't think there's going to be much difficulty determining which private field is referenced; UIM, it'll be similar to how `virtual' methods are traced.
This is what I get while trying to do this:
TException.eph:86: error: cannot overwrite data field `ObjectStructure' of parent object TException.eph:85: error: duplicate field `ObjectStructure'
Using build 20040516 (binary distro).
I'm not sure how other compilers handle this, but, IMVHO, this behavior is desirable.
private hiddens from outside world, not from descendants of an object.
Maurice
private hiddens from outside world, not from descendants of an object.
Isn't that what `protected' is for?
Neil Santos wrote:
private hiddens from outside world, not from descendants of an object.
Isn't that what `protected' is for?
Yes, indeed.
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. (Perhaps it was meant for purposes similar to C++'s `friend'.)
Therefore, there can be conflicts even with private fields.
Frank
private hiddens from outside world, not from descendants of an object.
Isn't that what `protected' is for?
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.
This is an automatic reply. The message received is attached.
To prevent mail loops, you will not get this automatic reply again for one hour.
Please do not send mail to the address ih8mj@fjf.gnu.de! I use this address for posting to the GNU Pascal mailing lists only.
In my view, replies to mailing list messages should almost always go to the list as well. [1], [2]
So if your mail is a typical reply to a thread on the mailing list (which you may have inadvertently sent to me instead of the list) or the start of a new thread, please resend it to the list.
If you replied to both the list and my address, you can ignore this message, since I get your mail via the list like everyone else. IMHO, replies to a list should not be copied to the author if the author is a reader of the list. [3]
If you really intend to send me a personal message (and only then), please resend it to my regular address frank@pascal.gnu.de.
Otherwise, if you did not and will not resend it to the list, your mail will not be read!
I'm sorry for the trouble this may cause you, but since I've been getting a number of mails to my personal address recently that should have been sent to the lists, and because using a `Reply-To' header in the lists is not generally accepted [4], I have to take such a drastic measure.
Regards, Frank Heckenbach
Rationales:
[1] Some people claim that "simple" replies should be sent by personal mail rather than to the mailing list (or newsgroup) where the request was posted so other readers of the list will not have to bother reading them. I do not agree. There may be others interested in the reply (one can never know, since "me too" requests are also frowned upon -- rightfully IMHO). Also, others might take the effort of replying as well when they don't know a reply was sent personally. In my opinion the wasted effort of writing an unnecessary second reply weighs much more than having to read a few unnecessary mails. Besides, those not interested in a topic can just ignore the thread.
[2] Some also claim that "exotic" or complicated requests can (or should) be sent directly to a knowledgeable person rather than to the usual mailing list (or newsgroup). I also don't agree. First, it's hard to tell (especially for the one asking the question) who really is the most adept to answer this particular question. Also, someone else may have the same or a similar question now or in the future. If the request (and possible replies) appear in the list and its archives, there is at least a chance that others will see it and not have to ask the same question again. Even if this doesn't happen always, it's more important IMHO than having to read a few mails too many on the list.
[3] Some people claim one should "Reply to all" in mailing lists. Again, I don't agree. Receiving the mail twice, via the list and directly, is a waste of my bandwidth and time. (BTW, I think there should be a "reply to mailing list" feature. But until this is universally supported and standardized, including the necessary headers to be set by MLM software, it's up to those replying to make sure replies are directed appropriately.)
[4] See http://www.unicom.com/pw/reply-to-harmful.html for some reasons. I do not agree to many of the points, and may write a counter-statement someday if anyone cares ...
Neil Santos wrote:
private hiddens from outside world, not from descendants of an object.
Isn't that what `protected' is for?
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.
Frank
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
-
Frank Heckenbach -
frank＠g-n-u.de -
Maurice Lombardi -
Neil Santos