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: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: MI for Ada Date: 1999/02/16 Message-ID: #1/1 X-Deja-AN: 444971875 References: <36C365F8.50E84F94@averstar.com> <7a2j8q$meo@bgtnsc01.worldnet.att.net> <7a7aav$mse$2@plug.news.pipex.net> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada Date: 1999-02-16T00:00:00+00:00 List-Id: In article <7a7aav$mse$2@plug.news.pipex.net> "Nick Roberts" writes: > A blasphemy in 1983 perhaps, but not such a blasphemy now. Provided the > extended syntax is rejected when the compiler is in 'standard mode', and > accepted in some special mode (probably activated by a compiler flag), the > sacred snake remains in his lair. You have to understand that there are two roles involved, and most good language lawyers are also language designers, closet or otherwise. And as you are aware in Ada 83 the rule was "no unauthorized extensions." In Ada 95, there must be a standard conforming mode. One of the hopes for the GNAT project is that it will make trying out potential extensions much easier. 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. > 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. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...