Re: Eiffel and Java

[donh@syd.csa.com.au (Don Harrison)]

Jon S Anthony writes:

:First, we are speaking of interface/impl _separation_.  This was
:discussed to death in the Real OO thread.  There are several reasons
:why a) the "abstract class" trick in Eiffel is the correct analogue
:and b) it doesn't quite work.  In fact, you _agreed_ with this!  See
:below...

Well, it may have appeared that way to you (for a good reason) but wasn't 
the case. See below.

:Second, where do you get the idea that Ada doesn't support separation
:of interface and implementation inheritance????  Of course it does.
:This is _another_ thing that was pointed out several times in several
:ways by several people.  The implementation of a types interface can
:be done completely separately from any aspects it might inherit or not
:from its parent type.  It may in fact not use _any_ of its parent's
:operations in this implementation.  You may also have a case where you
:have the interface inherit some of the parent's implementation while
:defining new operations which will be implemented using other parts of
:the parent's implementation which are not part of the interface.

Yes, I appear to be wrong on this. I suspect this is different to how it
works in other languages (eg. Sather, Cecil) but that's another matter.
Actually, Sather's approach of using 'abstract' and 'concrete' classes is
probably your source of confusion. I don't know much about Sather but
I *do* know that it's abstract classes *are* used to define interfaces.
This is not the purpose of Eiffel deferred classes as I explain below.

:Correct and I recall that it became pretty clear to all what the
:issues were and why the two approaches (not separating and using a
:"short tool/form" and separating as in Ada...) were substantially
:different.  

When you say 'clear to all', I presume you're speaking on my behalf as well. 
I'll represent myself, if you don't mind. :(

For an example of the discussion, see below...

:> This is how I would 'match' these facilities in Ada and Eiffel:
:> 
:> Ada                                   Eiffel
:> ---                                   ------
:> package interface                     (output of short tool)
:
:Nope...  The output of the short tool does not get fed to an Eiffel
:compiler and in no way is a language entity.  You can't give a "short
:form" several different implementations, etc.

As you suggest, another use of separate interfaces is to facilitate separate
compilation. But the primary purpose of an interface is to provide a view of 
the abstraction and, for the Eiffel developer, that is provided by the short 
form. For separate compilation, the Eiffel system can generate a notional 
interface from the class text. This 'interface' can then be used in conjunction 
with the CM system to do all those nice things that you can do in Ada (eg. 
substitute a different implementation such as a stub). The Eiffel system might 
do this by generating the notional interface whenever a class is compiled and 
comparing it with the existing one (if any). If different, and the developer 
gives the go ahead, the notional interface can be updated. The CM repository 
can be used to hold different implementations of the same interface.
I don't know whether any Eiffel implementations provide this facility but
they should, IMO. As you know, this is very useful.

So, it is more accurate to say 

Ada spec (analogous to) Eiffel notional interface + short form.

:> package body                          class
:
:Nope.  As you by now know, an Eiffel class is (more or less)
:equivalent to a package exporting a tagged type interface.  Now, in
:Ada, you can implement this type's interface in various ways -
:including those where the

Yes, my comparison is inaccurate. Remembering that the Eiffel interface is
notional, the comparison should be more like

Ada spec + body + single enclosed tagged type (analogous to) Eiffel class.


:---Full article of donh reply to me...
:
:Subject:      Re: Real OO (was Choice of OO primitives in Ada95)
:From:         donh@syd.csa.com.au (Don Harrison)
:Date:         1996/03/11
:Message-Id:   <Do3FLw.50H@assip.csasyd.oz>
:Sender:       news@assip.csasyd.oz
:References:   <JSA.96Mar8143939@organon.com>
:Organization: CSC Australia
:Reply-To:     donh@syd.csa.com.au
:Newsgroups:   comp.lang.ada,comp.lang.eiffel,comp.object
:
:Jon S Anthony writes:
:
::In article <313F3415.F5A@venice.sedd.trw.com> "Matthew M. Lih" <lih@venice.sedd.trw.com> writes:
::
::> Another thing you can do in Ada is specify multiple implementations.
::> The common use of this is to have an implementation which returns
::> "dummy" results which people can use to test code which uses the
::> procedure. Meanwhile, the implementor can work on the actual
::> implementation. Is this possible in Eiffel?

BTW, this is what I'm suggesting *can* be done.

::Sure, but it is either a) more complicated, b) more dodgy or c) both.
::If you play the "abstract class" game (and write protect the file,
::ugh!) you can sort of crib this as the "abstract class" is a kind of
::"poor mans" package specification.  Of course, you now have two
::interfaces to deal with: the "abstract one" and the
::"actual/implementation" one.
:
:I agree. (That scared you, didn't it? :-)

Well, I have a confession to make to you, Jon. After 4-5 months of arguing
with you, I was fairly receptive to agreeing with anything you said - true 
or otherwise. In this case, I did agree with a little of what you said but 
not all. :)  I wasn't more specific because I was anxious to put an end to
the interminable argument so didn't want to provide more fuel for it. :(

Come to think of it, there isn't a lot in there I *do* agree with. :) 
It must have just been that using abstract classes to emulate separate
interfaces is misguided (dodgy). In fact, it's a misuse of abstract
classes. The point to realise is that languages are designed to do similar 
things in different ways. Using deferred classes in Eiffel to emulate separate interfaces, is misuse just as attempting to use Ada's information hiding 
mechanisms to simulate selective export is misuse. (The correct approach for 
Ada is to put all the closely-related types in the same package, as Norman 
Cohen pointed out. It isn't quite the same but it's the proper way of doing 
it in Ada).

Now, back to why deferred classes are not the analogue of separate 
interfaces. It has to do with the purpose of each. The purpose of Ada package 
specs is to provide a view to clients of the services of the abstraction and
to allow separate compilation. However, the purpose of abstract (deferred) 
classes is to provide a (possibly partially implemented) design template for 
a general abstraction. In doing so, it happens to define the interface to the 
abstraction but it also defines any implementation of parts of that abstraction. 
It also happens to confer the interface upon heirs but this is true of any parent 
class; it is not peculiar to abstract classes.

So, in terms of intended purpose, Eiffel deferred classes have more in 
common with Ada's abstract types. Also, the short form and notional interface
collectively offer similar functionality to package specs.

I hope this clarifies my position.

::The other course is to have two
::implementations: the "fake" one and the "real" one.  You then must
::trust the implementor of the "real" one to not change the interface.
:
:.... or use tools to control it?

This is an allusion to the Eiffel system managing different implementations
of a class in conjunction with the CM system.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au