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=0.1 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM,HK_RANDOM_FROM autolearn=no 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!postnews.google.com!h3g2000cwc.googlegroups.com!not-for-mail From: pnkflyd831@gmail.com Newsgroups: comp.lang.ada Subject: Re: 2 Ada 95/05 language design questions Date: 15 Feb 2007 14:59:34 -0800 Organization: http://groups.google.com Message-ID: <1171580374.075519.138610@h3g2000cwc.googlegroups.com> References: <1171556508.585271.80780@v45g2000cwv.googlegroups.com> NNTP-Posting-Host: 63.164.202.130 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1171580381 17053 127.0.0.1 (15 Feb 2007 22:59:41 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 15 Feb 2007 22:59:41 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: h3g2000cwc.googlegroups.com; posting-host=63.164.202.130; posting-account=E0hQbAwAAAD2FlvvQq_2SWp8Ek2yl3o- Xref: g2news2.google.com comp.lang.ada:9347 Date: 2007-02-15T14:59:34-08:00 List-Id: On Feb 15, 3:35 pm, Robert A Duff wrote: > pnkflyd...@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. > 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. > > 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"? You still have to with in the parent tagged types package. When refactoring this can still be annoying, but other languages have worse problems so it's definitely no deal breaker.