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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,be30d7bb9651853b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-12-20 12:50:22 PST Path: nntp.gmd.de!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!psuvax1!uwm.edu!news.alpha.net!news.mathworks.com!europa.eng.gtefsd.com!library.ucla.edu!agate!blanket.mitre.org!linus.mitre.org!linus!mbunix!eachus From: eachus@spectre.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.ada Subject: Re: Ada 90 inheritance request? Date: 20 Dec 94 10:40:21 Organization: The Mitre Corp., Bedford, MA. Message-ID: References: <3ca3vl$n14@lang8.cs.nyu.edu> NNTP-Posting-Host: spectre.mitre.org In-reply-to: jgoodsen@treasure.radsoft.com's message of 19 Dec 1994 18:58:59 GMT Date: 1994-12-20T10:40:21+00:00 List-Id: In article jgoodsen@treasure.radsoft.com (John Goodsen) writes: > Maybe it's just me not seeing something here (which could be an indicator > of the usability issues involved with addressing MI in Ada95), but where > is the polymorphic behavior in the MI lattice? Wouldn't the above solution > require me to delegate methods to the NF member of Ctrl_T (by hand)? You lost me here. Initialize, Finalize, and Adjust have to be defined on NF, but not on Ctrl_T. All the operations on T are derived for Ctrl_T, and appropriate dispatching occurs. The ONLY issue, as has been discussed is if you need finalization, etc. for some part of the inherited T, or if you need access to the inherited parts of T to do the initialization, etc. But as I (and others) see it, the major problem in that case is the broken abstraction, not the unsafe approaches to implementing the operations. > This isn't clear to me. Can you give an example (besides the overused > diamond inheritance pattern) ? What do you mean by "unsafe MI" ? The easiest definition on a large project is any case where a new subclass of one of the parents (or a change to one of the existing subclasses) can break the MI inheriting class. The usual break is when a new subclass of class A has a method which conflicts with a method inherited from class B, and you apply a class-wide operation of the MI class to a member of that subclass (with casting as necessary). You can get a dispatching call in some other method which now calls the "wrong" method, and there is no point visible to a single programmer where all this is visible. That's the major "doesn't scale" problem. Ada 9X avoids it by insisting that both of the methods involved must have a common template inherited from a single parent. If you have two mix-ins with the "same" method, the visibility rules, not the dispatching rules determine which gets called. (Unless, as stated, they both explicitly match a template in a superclass. But in that case, we do have a warning flag.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...