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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!newsfeed.datemas.de!feeder.erje.net!eu.feeder.erje.net!news2.arglkargh.de!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: 'Protected' abstract subprograms Date: Mon, 13 Jan 2014 21:45:24 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <839fee13-2743-49f6-a7f3-f95578386201@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1389671126 26161 69.95.181.76 (14 Jan 2014 03:45:26 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 14 Jan 2014 03:45:26 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:18164 Date: 2014-01-13T21:45:24-06:00 List-Id: wrote in message news:b7ef903a-26f8-4cbc-b137-0f35fe5be406@googlegroups.com... On Friday, January 10, 2014 5:30:55 PM UTC-5, Randy Brukardt wrote: >> You're very confused. Ada takes privacy *very* seriously, something other >> languages barely try. One of the Ada design's unchangable rules is that >> the >> legality of a client can never be affected by anything in the private >> part >> of tha package. (The private part can only affect the runtime behavior.) >> We've abandoned many good ideas over the years because of this issue -- >> it's >> the same reason that interfaces cannot be hidden. If we allowed abstract >> operations in the private part, then the legality of extensions would >> depend >> on the contents of the private part -- or we'd have to convert that into >> a >> runtime check rather than a compile-time one, which is the wrong >> direction >> to go. >Unfortunately, I am often confused :-(. The idea that the private part >cannot invalidate >the client is a good rule, but there often seems to be exceptions and >loopholes with child >packages; i.e. if I extend a type in a child package by adding a few >elements, and then >go back and try to add those elements to the parent, I get a compile-time >name conflict >error in the child. This implies that the child package is not technically >a 'client', but just >a logical extension of the parent. Correct. > But if that's the case, then the child package could also 'see' an > abstract subprogram in >the private part, and could in theory overload it. Yes, but that would require some way of specifying that the private type cannot be extended anywhere *other* than a child of the package containing the private type. Without that (and Ada doesn't have it now), you would either have to break privacy (by making such non-child extensions illegal, which for compatibility could only be the case if private abstract operations were used) or convert it into some sort of runtime check. (Ugh.) The point is that Ada doesn't have a limitation of WHERE you can write an extension. One could imagine adding an aspect for such a purpose (it would be a lot like Preelaborable_Initialization, which solves a similar problem for private types used to declare objects in Preelaborable packages). But in the absence of such an aspect or other marker, you would have to break privacy, and that's a non-starter for Ada. As I said last week, Ada takes privacy very seriously, and that definitely makes the language design harder (but generally is an advantage to users and especially to maintainers of abstractions -- because they don't have to worry about users depending on most characteristics.) Randy.