Re: Eiffel and Java

[jsa@alexandria (Jon S Anthony)]

In article <EACHUS.96Nov4184435@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> In article <JSA.96Nov2201641@alexandria> jsa@alexandria (Jon S Anthony) writes:
> 
>   > You mean something like, how does this work if you keep extending
>   > the queues?  That should be OK.  If you mean something like, I
>   > have a _different_ priority_queue thingy here (not derived from
>   > queues) - will it just fit in and work?  No, that will require
>   > going back and futzing...
> 
>    This looks like a case where you want interface inheritance, so
> implement interface inheritance:
> 
>    generic
>      type Stack_or_Queue is limited tagged private;
>      type Element is tagged private;
>      with function Pop(SQ: in Stack_or_Queue) return Element'Class is <>;
>      with procedure Push(E: in Element; Onto: in out Stack_or_Queue) is <>;
>      with function Is_Empty(SQ: in Stack_or_Queue) return Boolean is <>;
>      -- etc.
>    -- your procedure, function, or package goes here.
> 
>    For any Stack, Queue, Deque, etc., which matches the interface you
> can instantiate your generic.  You can even figure out a meaningful
> definition of Is_Empty for a queue connected to a pipe if that is what
> you have.  (For example, delay until the other end of the pipe is
> closed and return false, or until another element is put into the pipe
> and return true.)

Right.  Actually, what occured to me after I wrote that was that this
sort of example should be dealt with by means of generic formal
package parameters.  After all, defining this sort of "generic"
signature is one of the very things that they were defined for...

I suppose (since I've gone this far along) that I should write up the
example using this technique.  I am pretty sure it will be about
exactly what one wants in this sort of case.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com