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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,93553f5160def2e9 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!feeder.news-service.com!proxad.net!cleanfeed1-a.proxad.net!nnrp18-2.free.fr!not-for-mail Return-Path: From: "Randy Brukardt" To: Subject: RE: 2 Ada 95/05 language design questions Date: Thu, 15 Feb 2007 19:51:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1171580374.075519.138610@h3g2000cwc.googlegroups.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Trash-Finder: Limited filtering for message, local (outbound) source X-Virus-Scanned: amavisd-new at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.9rc1 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.ada Message-ID: X-Leafnode-NNTP-Posting-Host: 88.191.17.134 Organization: Guest of ProXad - France NNTP-Posting-Date: 16 Feb 2007 02:55:01 MET NNTP-Posting-Host: 88.191.14.223 X-Trace: 1171590901 news-2.free.fr 26338 88.191.14.223:56790 X-Complaints-To: abuse@proxad.net Xref: g2news2.google.com comp.lang.ada:9349 Date: 2007-02-16T02:55:01+01:00 pnkflyd831@gmail.com writes: > On Feb 15, 3:35 pm, Robert A Duff > wrote: ... > > One solution would be to have some syntax that means "this type might > > have some private abstract operations, and therefore all derivations > > from it must be in places where the full type is visible". But I don't > > think you want to treat ALL types that way. > > > > Your absolutely correct. My intent was not that all derived type > linages must match the package lineage. Additional syntax or the fact > that the private abstract subprogram is still visible from the spec to > the compiler and it could complain at compile time when you attempt to > create a child that doesn't have the full type visible. Additional syntax is OK. Making the legality of uses (in this case, derived types) depend on the contents of the private part is not OK. Doing so breaks encapsulation, in that a supposedly innocent change could cause all kinds of unrelated code to fail. I'm mildly surprised that you didn't mention the "no hidden interfaces" rule of Ada 2007, because that seems to me to be much more problematic than declaring a hidden abstract operation. OTOH, if you think of interfaces as properties of a type (either a type has one or it does not; a type cannot have one more than once), it makes more sense. But I've often thought that I'm the only one with that particular model... Randy.