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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fd96375b28b3103b X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,fd96375b28b3103b X-Google-Attributes: gid1108a1,public From: "John Goodsen" Subject: Re: "Classes" as packages in Ada Date: 1998/11/25 Message-ID: <3UU62.124$8X3.638914@news.rdc1.az.home.com> X-Deja-AN: 415544526 References: <73f0p1$4iu8$1@prime.imagin.net> <1103_911962898@DZOG-CHEN> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: RADSoft NNTP-Posting-Date: Wed, 25 Nov 1998 06:55:59 PDT Newsgroups: comp.lang.ada,comp.object Date: 1998-11-25T00:00:00+00:00 List-Id: So my conclusion is that Ada code for an interface is not even close in simplicity (from the programmer's point of view) as something like: public class ObserverEvent { ... } public interface Observer { public void Update(Observable); } public interface Observerable { public void AddObserver(Observer); public void RemoveObserver(Observer); public void NotifyObservers(Observer, ObserverEvent). } Is it? And that's been my point all along. Any goals of making Ada generally acceptable were, IMHO, just paid a bit a lip service and now we've got this beautiful, powerful language that scares the hell out of people from trying it out. It's a shame. -- John Goodsen RADSoft / Training, Mentoring and Consulting in: jgoodsen@radsoft.com - UML modeling and OOA/D principles http://www.radsoft.com - Use Centered Object-Oriented Design 888.298.2566 - Rapid Incremental S/W Delivery Process Ed Falis wrote in message <1103_911962898@DZOG-CHEN>... >On Tue, 24 Nov 1998 20:15:40 GMT, "John Goodsen" wrote: >> BTW, this brings up a curious point. How do you implement an <> >> in Ada? Sorry if it's a simple answer - but's its been a few years now >> since I've touched an Ada compiler. >> > >Well, I'm willing to take a crack at it. It's actually a specific instance of the most general (but not only) way of doing multiple inheritance in Ada. For mix-ins, generics with a >formal derived type offer a more straightforward approach. > >Suppose we've put together a portion of a design in the form of a role model (a la Reenskaug) or a collaboration diagram. What we want to do is define a class (or tagged >type in Ada parlance) that implements one or more roles. We can choose to have some behavioral implementation associated in general with the role, or keep the whole thing >abstract as in a Java interface. > >So, suppose we look at the publish-subscribe / observer-observalbe pattern. In Ada style we'd likely put the entire pattern into a single package, since it doesn't make a lot of >sense to define one with out the other. (I'm hoping my mailer preserves indentation here): > >package Publish_Subscribe is > -- "Push" information associated with observer notification, > -- basically a "command" subpattern: > type Event is abstract tagged limited private; > type Event_Ptr is access all Event'Class; > > procedure Action(This: access Event; Subject: access Observable'Class) is abstract; > > -- The publisher/observable interface / role: > type Observable is abstract tagged limited private; > type Observable_Ptr is access all Observable'Class; > > procedure Add_Observer(This: access Observable; Obs: access Observer'Class); > procedure Delete_Observer(This: access Observable; Obs: access Observer'Class); > procedure Notify_Observers(This: access Observable; Evt: access Event'Class); > > > -- The observer interface / role: > type Observer is abstract tagged limited private; > type Observer_Ptr is access all Observer'Class; > > > procedure Update( > This: access Observer; > Source: access Observable'Class; > Evt: access Event'Class) is abstract; > > >private > -- Infomation necessary for the compiler to physically handle the defined types/classes: > type Event is abstract tagged limited null record; > > type Observable is abstract tagged limited record > -- Head of a naive list implementation: > Observers: Observer_Ptr; > end record; > > type Observer is abstract tagged limited record > -- Pointer to next observer in the naive list implementation > Next_Observer: Observer_Ptr; > end record; > >end Publish_Subscribe; > > >Note that the approach taken here is to provide an implementation of common parts of the role. Therefore, the various methods other than Action for the Event type, and >Update for the Observer are not abstract - they're involved with a common implementation used for the Observer/Observable pattern. Also note that the three typed defined >are all abstract - one never creates a role "object" directly. I've left out the implementation of the concrete methods here. > >Now, supposing we want to define a class or type of object that implements the observer role. First we create a concrete observer class relative to object we wish to create: > >-- Forward reference to the type implementing the observer interface:: >type Implementing_an_Observer; > >-- Just a way to look at the implementing class as an observer. >-- The "access" parameter "This" allows access to other views and fields of an instance of the class: >type Observer_Role(This: access Implementing_an_Observer) is new Observer with null record; > >-- Provide an implementation of the abstract update method: >procedure Update(This: access Observer_Role; > Source: access Observable'Class; > Evt: access Event'Class) ; > >-- Full definition of the implementing type: >type Implementing_an_Observer is record > -- view allows looking at a type instance as an observer: > Observer_View: aliased Observer_Role(Implementing_an_Observer'access); > -- Other fields, possibly providing other role views >end record; > > >Having declared an object: > >Obs: Implementing_an_Observer; > >we can now look view it as an observer like so: > >Add_Observer(Some_Model, Obs.Observer_View'access); > >Any number of subfields can provide different views of the object corresponding to multiple inheritance, with the concrete type for the view either inheriting methods or >overriding them. A fully abstract role description corresponds to a Java interface. > >This IS a bit cumbersome when you first run into it, but it's pretty straightforward once you get the idea, and it's extremely flexible. It also avoids the multiple inheritance >diamond problem since each view has its own associated members. > >And, as I mentioned, if you just want to do a decorator or similar mix-in, a generic with a formal that allows anything inheriting from some type provides a simpler mechanism for >such more common uses of multiple inheritance. > >- Ed > >