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-15 18:41:24 PST Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!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: 15 Dec 94 18:41:24 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 14 Dec 1994 19:49:49 GMT Date: 1994-12-15T18:41:24+00:00 List-Id: In article jgoodsen@treasure.radsoft.com (John Goodsen) writes: > Of course, I don't really expect the ivory tower league to > undertake such a revealing comparison. It makes too much sense > and would expose the err in the MI reasoning process. Keeping > your balance on the soapbox seems to take priority over putting > Ada into the mainstream communities. Never being afraid to jump into the fray, I'll respond to John by taking his MI example and asking why the obvious Ada 95 version is not acceptable: type Needs_Finalization is new Controlled with...; -- overriding of Initialize/Adjust/Finalize procedure Initialize (Obj : in out Needs_Finalization); procedure Adjust (Obj : in out Needs_Finalization); procedure Finalize (Obj : in out Needs_Finalization); type Ctrl_T is new T with record NF: Needs_Finalization; end record; Now I can think of cases where this won't work, but they are precisely the cases where the "true" MI version won't work either. No, I take that back. There are cases where true MI will fail, and the Ada 95 version will sail through. For example, if someone modifies T so that it inherits directly from Controlled... In general where Ada 95 says "this is unsafe, so we will not allow it," most MI languages say "this is really neat, and if you are VERY careful, it will work, but never on large projects, because it doesn't scale well." I've been there, I've done that, I've seen the maintenance nightmares that can occur when more than one programmer depends on unsafe MI on the same project. There is a lot of reasonable, and safe, MI out there. But if you check, it is all easily (and cleanly) translatable to Ada 95. In this case, I think it was Tucker who gave exactly the right answer--if Ctrl_T needs to modify parts of T as part of assignment or finalization, you really need to think long and hard about whether or not other descendants of T will need to do the same thing. If so, the right choice is to make T a (direct or indirect) child of Controlled. If not then you are almost certainly breaking the class model for T. (Making Ctrl_T the root of it's own class, or the part of a class rooted at Controlled, and having it add the "T" abstraction as a component or mix-in is easy, if a solution without the "is a" property is correct.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...