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/19 Message-ID: X-Deja-AN: 197343480 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-19T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > :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. Well - yes, I know that is how Sather works in this area. I meant that in the Eiffel case you would have to fake this with a class which you happen to "really implement" by means of another separate class. I am not talking about Eiffel deferred classes here per se and is why I used the scare quotes around "abstract class". I was the one saying that these are DIFFERENT. Go back and check out the thread. > :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. :( So, you don't think the approaches _are_ different?????????!?!?!?! I'm not saying any one ever agreed on what was "right" - just that they are in fact different! I can't imagine how anyone could say they are the same. But you never know... > 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). Well, I wouldn't say "all" - there is no way to semantically check this stuff is consistent across its potential clients (well probably not - unless the add on tools understood Eiffel semantics as well as an Eiffel compiler). > 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. Agreed. > Ada spec + body + single enclosed tagged type (analogous to) Eiffel class. Agreed. > :---Full article of donh reply to me... >[snip...] > > 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. :( Sounds reasonable. > interfaces is misguided (dodgy). In fact, it's a misuse of abstract > classes. Agreed. But it is about the only way with current out of the box Eiffel to get this sort of capability. > 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 Agreed. > 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). The only way to get selective export (in a limited form) in Ada is with child units. This works fine and is a proper use but is not as general as the Eiffel approach. But I see your intent here and basically agree with it. > So, in terms of intended purpose, Eiffel deferred classes have more in > common with Ada's abstract types. Absolutely - and I never said otherwise. You have apparently mistook my "abstarct class" notation as referring to Eiffel _deferred classs_. Not so. > Also, the short form and notional interface collectively offer > similar functionality to package specs. Well - if all that other machinery existed, this would be true. But even then, it would not be part of the Eiffel language - rather add on tools. > I hope this clarifies my position. Yip. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com