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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f4f6a5b783e1150c X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: MI for Ada Date: 1999/02/17 Message-ID: #1/1 X-Deja-AN: 445492945 References: <36C365F8.50E84F94@averstar.com> <7a2j8q$meo@bgtnsc01.worldnet.att.net> <7a7aav$mse$2@plug.news.pipex.net> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.ba.best.com 919292573 206 bpr@206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-02-17T00:00:00+00:00 List-Id: On 16 Feb 1999, Robert I. Eachus wrote: > The extension of generics that I suggested is mostly syntactic > sugar, but I think it is the kind of extension that "Makes Ada more > Ada-like." It makes such tailorable generic packages easier for the > reader to understand. Instead of a generic with dozens or hundreds of > formal parameters, you make it clear you are declaring the interface, > and the instantiation must provide a body. A perfect example of how > to use this is sorting. You could have a package with a (generic > formal subprogram) parameter which indicates the sort algorithm > desired. This is possible now, I was just suggesting a much cleaner > syntax. I'd be interested in seeing some more examples of your proposal in use, since I don't think I understand its semantics yet. > > Actually, it occurs to me that there is no particular difficulty in > > providing multiple inheritance from several publicly null-record tagged > > types at the same time. The new type would have to implement all the > > promised subprograms of both/all its parents, and (probably) it would have > > to be illegal for any such subprograms to 'overlap' (have same name & > > profile). Class membership tests for such types could be implemented by > > chaining the descriptors in series (the user would never know). > > Actually you don't need the rule about overlapping, you can either > have a rule about precedence order, or better, require that any such > subprogram be explicitly overridden, with the possible exception of "=". > That seems much more like the Ada way. > > > Something for Ada 200X, perhaps? > > There is a major difference between making multiple inheritance > workable, and making it useful. I'm convinced that for Ada, the first > is possible, but with the mix-in idiom that is very usable now, I > don't see what "true" multiple inheritance gains other than to confuse > the definition of parent type. How about "false" multiple inheritance, a-la Java, Objective-C, GNU C++ with signatures, etc? Following the GNU C++ idea, we create some new entities, signatures and signature access types. These signatures correspond directly to Java interfaces, and the signature access types are there so that you can declare variables which conform to a signature. I think the general idea is fairly simple, and provides something that Ada doesn't handle well right now with its mix-in idioms. Unfortunately, I suspect the integration into Ada requires someone with a bigger brain than mine, or at least one that lives and breathes RM and AARM :-). -- Brian