From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,16b1ef91d331648c X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Barnes vs. Dewar Date: 1999/08/30 Message-ID: #1/1 X-Deja-AN: 518856577 Sender: bobduff@world.std.com (Robert A Duff) References: <37C66E08.16DB@dera.gov.uk> <37c6fe0a@news1.us.ibm.net> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-08-30T00:00:00+00:00 List-Id: "Matthew Heaney" writes: > Wow! I didn't know you could do that. I just assumed that once private, > then always private, for all descendents. Take a look at 7.3.1. Remember we're talking about a derived type in a child package here -- when we get to the private part, all kinds of information about the parent type become magically revealed. In particular, we inherit a subprogram. Now, given that there's an explicit subprogram with the same name and parameter types, what can we do? Making it override the implicit one is really the only sensible answer. > Good question. It's bad enough that a controlled operation is public, but > it's even worse when public-ness only applies to some types in the class. I don't think it's so horrible. There might be cases where you want to call Initialize or Finalize explicitly, so you want to make them public. And that might apply only to one sub-hierarchy. So you get the choice of deriving publicly or privately from Controlled. Shrug. Note that if you derive publicly from Controlled, the operations are visible outside the package, whether or not you overrode them, and whether or not you put the overridings in the private part. I think my previous message might have been misleading on that point... - Bob -- Change robert to bob to get my real email address. Sorry.