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,e94a7e4f6f888766 X-Google-Attributes: gid103376,public From: "Matthew Heaney" Subject: Re: Self-referential types Date: 1999/10/12 Message-ID: <3803c8bc_2@news1.prserv.net>#1/1 X-Deja-AN: 536023335 Content-transfer-encoding: 7bit References: <7ttb4a$8mq$1@nnrp1.deja.com> <3802f2db_2@news1.prserv.net> <3803B5E3.F96A6DD4@mitre.org> Content-Type: text/plain; charset="US-ASCII" X-Complaints-To: abuse@prserv.net X-Trace: 12 Oct 1999 23:48:12 GMT, 129.37.62.159 Organization: Global Network Services - Remote Access Mail & News Services Mime-version: 1.0 Newsgroups: comp.lang.ada Date: 1999-10-12T00:00:00+00:00 List-Id: In article <3803B5E3.F96A6DD4@mitre.org> , "Robert I. Eachus" wrote: >> This is the basis for programming with access discriminants, which is >> how you do MI in Ada95. > > I have to butt in here. It may be how you do MI in Ada, and it is > one way, but I find it ugly. If you treat a private access type as the > object, then you have to do a bit more work inside the package, but the > exterior looks much cleaner, and the users don't have to use 'Access at > all. (Often you don't need it inside the package either.) I think we're in agreement. I use access discriminants (indeed, taggedness) strictly as an implementation technique. As much as possible you want to push the type composition infrastructure into the private part of the spec. For example, most of my observer types only privately derive from Observer_Type; the public part is just "limited private." with Clock_Timers; package Digital_Clocks is type Digital_Clock (Timer : access Clock_Timer'Class) is limited private; private type Control_Type (Clock : access Digital_Clock) is new Limited_Controlled with null record; type Digital_Clock (Timer : access Clock_Timer'Class) is new Observer_Type (Timer) with record Control : Control_Type (Digital_Clock'Access); --!!! end record; end Digital_Clocks; Here, Digital_Clock "multiply inherits" from two different parent types. All the machinery is hidden in the private region, exactly where it belongs. I do one better when I observe two subjects simultaneously: with Master_Timers; with Slave_Timers; package Digital_Clocks is type Digital_Clock (Master : access Master_Timer; Slave : access Slave_Timer) is limited private; private type Master_Obs_Type (Clock : access Digital_Clock) is new Observer_Type with null record; type Slave_Obs_Type (Clock : access Digital_Clock) is new Observer_Type with null record; type Control_Type (Clock : access Digital_Clock) is new Limited_Controlled with null record; type Digital_Clock (...) is limited record Master_Obs : Master_Obs_Type (Digital_Clock'Access); Slave_Obs : Slave_Obs_Type (Digital_Clock'Access); Control : Control_Type (Digital_Clock'Access); end record; end Digital_Clocks; Here, Digital_Clock "multiply inherits" from three different parent types. But all the machinery is hidden in the private region, exactly where it should be. In recent article I showed how to observe individual attributes of a subject, as compared to observing the subject itself. If you declare the observer types as children of the subject, then you can even hide the fact that the subject derives from Subject_Type. Some guys use public taggedness everywhere with gay abandon. This is wrong. Don't use taggedness unless you need to, and if you do, then hide it in the private region if you can. Under no circumstances should you have deep inheritance hierarchies. Make hierarchies broad and shallow; say, an abstract parent type and a non-abstract sibling derivations. (This is the approach I use over and over again in my articles in the Design Patterns archive.) I realize this is not the OO approach of other languages, but the benefits are that you have far less coupling. These examples (and many more) can all be found in the design patterns archive. I will be discussing this technique this Sunday (17 Oct 99) during my Design Patterns tutorial, at this year's SIGAda conference. Matt -- The political forces that try to eliminate evolution from science classrooms impose a narrow, sectarian doctrine on our educational systems. This imposition represents an affront not only to the constitutional separation of church and state but also to the moral and intellectual integrity embedded in that constitution.