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=ham 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!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nwr.nac.net!newspeer.monmouth.com!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: 2 Ada 95/05 language design questions Date: Thu, 15 Feb 2007 15:35:09 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1171556508.585271.80780@v45g2000cwv.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1171571709 28587 192.74.137.71 (15 Feb 2007 20:35:09 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 15 Feb 2007 20:35:09 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:jctzJG5D549gnHt0lpiiGhywDYw= Xref: g2news2.google.com comp.lang.ada:9345 Date: 2007-02-15T15:35:09-05:00 List-Id: pnkflyd831@gmail.com writes: > I find Ada to be an excellent embedded, real-time, OO language. > However I've noticed over the course of my 3 years programming with > the language 2 ways in which the language behaves that I question the > designers on their rationale. Interesting ideas. > The first question deals with the decision not to allow the > declaration of abstract subprograms within the private part of a > package (that contains a public abstract tagged type, and uses it as > the controlling operand). See Ada 05 LRM section 3.9.3(10). The > Annotated LRM gives a rational (derived tagged types not declared in > child packages would not have visibility to these abstract > subprograms), but wouldn't the better option to be to force derived > tagged type to be declared in the same or child packages than to have > to make public the abstract subprogram? I do not like the idea of > allowing external objects access to methods that could potentially > leave the aforementioned class objects in an inconsistant state. > (Attempts to impliment the Template Method design pattern suffer from > this issue) That's a legitimate complaint. However, I think you're suggested cure is worse than the disease. You're saying that all (tagged?) type derivations must happen within the same hierarchy of child packages, right? That seems like an onerous restriction, to me. Quite often, you want clients, with no visibility on the private part, to derive from the type and override some operations. Consider some of the predefined types. I don't think you want all controlled types to be declared in children of Ada.Finalization, nor all types derived from Root_Stream_Type to be declared in children of Ada.Streams! 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. > The second question deals with the decision not to have derived tagged > types inherit the "primitive" classwide subprograms of their publicly > declared parents. See Ada 05 LRM section 3.4(16,17/2, & 23/2) which > states that only primitive operations are inherited and made visible. > In Ada 95 it seems silly to have to with in the package where the > classwide subprogram is declared to use it, and then the package > reference has to be repeated every time the classwide subprogram is > called unless a use clause is present. The calling object should not > have to distinguish between dispatching and classwide operations when > they have a child derived type view of the object. In Ada 05, the > impact is less severe because of the dot notation, but I am still > curious as to why the decision was made. (Code which works with the > child derived type object instead of the parent view of the object > suffer from this issue). Again, a legitimate complaint. In fact, various people complained about this over the past decade, and the response was to add the dot-notation call syntax in Ada 2005. You say that makes the "impact less severe". Would you agree with "eliminates the problem"? As to why it was done that way in the first place, well, I suppose we didn't think it was that big of a deal. Sure, you have to track down the package where the class-wide op is declared, and 'with' that package, and say "Package_Name.Blah(...)" or else "use Package_Name". The idea of inheriting class-wide operations never occurred to me; it just seems weird to me, since there's really only one of it, and you can't override it. In a from-scratch language design, I would consider attacking the problem by liberalizing the visibility rules (e.g. making with_clauses transitive). - Bob