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: fac41,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java Date: 1996/11/14 Message-ID: X-Deja-AN: 196345666 sender: news@organon.com (news) references: <32821C82.2D32524D@sede.unijui.tche.br> organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-14T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > Marcos F. F. de Macedo writes: > > :Jon S Anthony wrote: > : > :> Right. As was pointed out back in that old thread, to get at the > :> "separate" spec/impl aspects in Eiffel you would use an "abstract > :> class" technique. This doesn't quite work, but it is at least the > :> proper analogue. > > Jon, don't know why you say this. I have some vague recollection of you > talking about Sather's separate interface and implementation *inheritance*. > But Ada doesn't even support that, so I'm not sure what you're thinking > of. Please explain why you make this association. Don, what on Earth are you talking about? 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... 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. > :There is no need to write the interface if it could be stracted from the > :source code. I should know that Ada was based on Modula-2 that used this > :way of separating. Oberon, the sucessor of Modula-2, uses automatic > :interface generating tool. > > I'm with you on this. Your point was raised in the "Real OO" thread Jon > refers to. 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. 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. > 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 OK, I actually went back and found a couple of relevant articles: ---Partial article from me replying to mbk replying to someone... > > And as for separating specs and implementations, Ada > > is the only language that does it nicely, without giving up safety. > > This isn't true. Correct, M3 (and M2) for example provide this as well. > You write abstract classes in Eiffel/Sather/C++ which has the spec > (including pre/post/invariant) and write an implementation class which > supports it. > > What is the problem? I don't know. But it is not the same. You still have the interface of the so called "implementation" class which is inextricably hooked to _its_ implementation. The fact is that Meyer (for various reasons) decided _against_ separation of interface and implementation. So, if you are going to argue about this, you should be arguing about whether this choice was "a good idea" (and not pretending that it isn't true). ---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: Sender: news@assip.csasyd.oz References: 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" 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? : :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? :-) :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? :/Jon :-- :Jon Anthony :Organon Motives, Inc. :1 Williston Road, Suite 4 :Belmont, MA 02178 : :617.484.3383 :jsa@organon.com Don -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com