Re: "Classes" as packages in Ada

["John Goodsen" <jgoodsen@radsoft.com>]

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" <jgoodsen@radsoft.com> wrote:
>> BTW, this brings up a curious point.  How do you implement an <<interface>>
>> 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
>
>