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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: How come Ada isn't more popular? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: Date: Sat, 10 Feb 2007 10:15:24 +0100 Message-ID: NNTP-Posting-Date: 10 Feb 2007 10:15:07 CET NNTP-Posting-Host: 56864b70.newsspool4.arcor-online.net X-Trace: DXC=eJf1V4SJS0m]l@YUW5NBkn4IUK On Fri, 9 Feb 2007 22:18:51 -0600, Randy Brukardt wrote: > Dmitry A. Kazakov writes: > ... >> Because it does not compose upon inheritance and aggregation. >> >> When inherited the constructing function need to be overridden, even if >> null record was the only thing added. > > That's not true in Ada 2007. (That's a change I strongly opposed, BTW, > because it makes prototyping much harder. I usually start an extension with > a null record, figure out what needs to be overridden (giving those null > bodies), and then implement the actual routines and data. This no longer > works, because as soon as you add an extension component you are back to > square one.) Yuck. Do I understand correctly, primitive operations are no more covariant in the result? type T is tagged ...; function Foo return T; type S is new T ...; -- I don't need to override Foo???? >> Further one can barely publicly >> derive anything from T, which breaks encapsulation. > > Not sure what you mean by this. It's certainly possible for a deivation to > break encapsulation (by deriving in a child unit, for instance), Which is not always desirable or even possible, as we don't have multiple parents (alas!). > It is annoying that we couldn't find a way to get composition to work for > anything other than :=, =, and stream attributes. I think that the problem is that we have no unified composition model for primitive operations. Things composed per magic (like ":=" or dispatching subprograms) use different rules. Why don't we try to expose this mechanics in the language? There certainly exist a common denominator of how operations are composed. It is either of: g := f o g -- f extends g g := g o f -- f prepends g g := f -- f replaces g g := e o g o p -- prologue and epilogue (conversion) -- (like in out Natural accepting actual Integer) All primitive operations including assignment, attributes, constructors (from raw memory to object's invariant), destructors (backwards), aggregates, conversions fall under some combination of these patterns. This could radically simplify the language (fully backward compatible of course). > (The lack of it for > finalization routines is especially aggrevating and error prone.) Yes, especially, because there is no name for parent's Initialize/Finalize. > But the > workarounds for constructors aren't particularly bad, especially as you can > use extension aggregates in your overridings. > > (F with ); Yes, aggregates compose (which is good), but they aren't functions. There is an underlying thing which IMO should be named and exposed. BTW, the aggregate above is almost equivalent to C++'s constructor definition Derived::Derived (...) : F(...), {} -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de