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-14 04:07:05 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!cmcl2!jpmorgan.com!jpmorgan.com!usenet From: jgoodsen@treasure.radsoft.com (John Goodsen) Newsgroups: comp.lang.ada Subject: Re: Ada 90 inheritance request? Date: 13 Dec 1994 19:02:47 GMT Organization: The Dalmatian Group, Inc. Message-ID: References: <3ca3vl$n14@lang8.cs.nyu.edu> NNTP-Posting-Host: treasure.ny.jpmorgan.com In-reply-to: comar@cs.nyu.edu's message of 9 Dec 1994 12:26:13 -0500 Date: 1994-12-13T19:02:47+00:00 List-Id: In article <3ca3vl$n14@lang8.cs.nyu.edu> comar@cs.nyu.edu (Cyrille Comar) writes: I am dismayed at how anyone could look at this so-called "solution" to multiple inheritance and walk away comfortable that Ada9X properly supports MI. The lack of *direct* support for MI in Ada 9X, is IMHO, a serious foobar that has to this point been explained away by the ivory tower language designers as either (a) something that I don't really need (thanks for being so luminiscent in my needs) or (b) if you really need it, it's only for abstract, mixin type class behavior which you can perform using SI and generics. Neither of which is an aesthetically or technically pleasing solution. So I'll go past the rhetoric of verbal, get-us-nowhere discussions on why *DIRECT* support for MI should or should not be in Ada 9X and propose a little excercise for one of those language designers who feel that direct MI support is not necessary: 1. Read and understand the Design Patterns book by Gamma et. al... If you haven't read this yet, then you are missing out on some great insight into designing reusable software. 2. Recreate in Ada9X some of the sample implementations of patterns that require MI as part of the solution. Post the Gamma et. al. C++ solutions and compare them to the Ada9X solution. I believe it will become quite obvious what a hack it turns out to be in Ada 9X. Tucker, sound like something you or your people could take on as a quick and dirty excercise? I think it would give you better insight into the problems. you up for it? speaking from my Wall St. cubicle... -- John Goodsen Currently on-site at: The Dalmatian Group JP Morgan User Interface Specialists 60 Wall St., New York City jgoodsen@radsoft.com jgoodsen@jpmorgan.com --- included message ---- stt@spock.camb.inmet.com (Tucker Taft) writes: : : Here is the note on multiple inheritance in Ada 9X. : -Tucker Taft Thank's Tuck for your very instructive note. I love this kind of post where I fill like learning something rather than listening to someone complains. By the way, I have an intersting challenge for our Ada9x experts. Here is a problem that would have an obvious solution with Multiple Inheritance, I would like to see how it can be solved cleanly in 9x. The problem is not abstract, this is something that everybody will need at some point. PROBLEM: I have defined a hierarchy or tagged types and now I would like specialize one of them to be controlled (i.e. finalizable) with MI, I could write something like: type Ctrl_T is new T, Controlled with null record; -- overriding of Initialize/Adjust/Finalize procedure Initialize (Obj : in out Ctrl_T); procedure Adjust (Obj : in out Ctrl_T); procedure Finalize (Obj : in out Ctrl_T); and it would be the end of it... Beginning of Solution --------------------- Following your suggestions, we could define a generic package: generic type T is tagged private; package Make_it_Controlled is type Ctrl_T is new T with private; procedure Initialize (Obj : in out Ctrl_T); procedure Adjust (Obj : in out Ctrl_T); procedure Finalize (Obj : in out Ctrl_T); private type T_Controller is new Controlled with null record; procedure Initialize (Obj : in out T_Controller); procedure Adjust (Obj : in out T_Controller); procedure Finalize (Obj : in out T_Controller); type Ctrl_T is new T with record Ctrl : T_Controller; end record; end; and then I need to be able to call Initialize on Ctrl_T inside the Initialize of type T_Controller. Each time a variable V of type Ctrl_T is defined the Initialize on V.Ctrl will be called and will itself call Initialize on V. But now I am stuck because there is no way in the body of Initialize on T_Controller to refer to the englobing object.... Argggg Tuck gave another nice trick by using access discriminant that solves partially the problem. We can use it to redefine the controller: type Acc is access all Ctrl_T; type T_Controller (Englobing_Obj : Acc) is new Limited_Controlled with null record; type Ctrl_T is new T with record Ctrl : T_Controller (Ctrl_T'Access); end; and now I can write Initialize procedure Initialize (Obj : in out T_Controller) is begin Initialize (Obj.Englobing_Obj.all); end; And everything would be nice if it was legal... The problem is that the access discriminant requires a LIMITED TYPE and thus Ctrl_T must be limited. So this approach works pretty well if my formal generic parameter is type T is tagged limited private; This package allows any limited tagged type to be specialized as a limited_controlled type (sort of). MY CHALLENGE is : how to do the same thing with non-limited types ? -- ------------------------------------------------------------------------ Cyrille Comar, E-mail: comar@cs.nyu.edu Gnat Project US phone: (212) 998-3489 -- -- John Goodsen Currently on-site at: The Dalmatian Group JP Morgan User Interface Specialists 60 Wall St., New York City jgoodsen@radsoft.com jgoodsen@jpmorgan.com