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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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: donh@syd.csa.com.au (Don Harrison) Subject: Re: Eiffel and Java Date: 1996/11/15 Message-ID: X-Deja-AN: 196597994 sender: news@syd.csa.com.au x-nntp-posting-host: dev11 references: organization: CSC Australia, Sydney reply-to: donh@syd.csa.com.au newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-15T00:00:00+00:00 List-Id: 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: :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? 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