comp.lang.ada
 help / color / mirror / Atom feed
From: Brian Rogoff <bpr@shell5.ba.best.com>
Subject: Re: MI for Ada
Date: 1999/02/17
Date: 1999-02-17T00:00:00+00:00	[thread overview]
Message-ID: <Pine.BSF.4.05.9902171348570.4251-100000@shell5.ba.best.com> (raw)
In-Reply-To: EACHUS.99Feb16110742@spectre.mitre.org

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






      parent reply	other threads:[~1999-02-17  0:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-11  0:00 MI for Ada Brian Rogoff
1999-02-11  0:00 ` Tucker Taft
1999-02-12  0:00   ` Robert I. Eachus
1999-02-12  0:00     ` Brian Rogoff
1999-02-13  0:00     ` Alexy V Khrabrov
1999-02-14  0:00       ` Nick Roberts
1999-02-15  0:00         ` robert_dewar
1999-02-18  0:00           ` Nick Roberts
1999-02-16  0:00         ` Robert I. Eachus
1999-02-16  0:00           ` robert_dewar
1999-02-16  0:00             ` Robert I. Eachus
1999-02-17  0:00           ` Brian Rogoff [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox