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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: nospam@thanks.com.au (Don Harrison) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/04 Message-ID: #1/1 X-Deja-AN: 269797797 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: Organization: CSC Australia, Sydney Reply-To: nospam@thanks.com.au Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-04T00:00:00+00:00 List-Id: Patrick Doyle wrote: :In article , :Don Harrison wrote: :>:>> >More to the point: not _relevant_ in the Ada case as this is handled :>:>> >by a different orthogonal capability :> :>Agree. Multiple, polymorphic implementations are provided by deferred classes :>and abstract types in Eiffel and Ada respectively. As Jon says, this is an :>orthogonal concept to interfaces. : :Thanks, but I didn't say that. I think Jon said it. Yes, he did and I was aware of it. I admit my attribution wasn't clear. :>:>> using a deferred class is more powerful than a simple interface :>:>> file, and can accomplish all the same things, so why split :>:>> this into two concepts? :> :>Because they serve different purposes. (See my previous post). : :But the deferred class can serve both purposes, can't it? Not in the Ada or Modula sense of the term "interface". I expect the situation is made somewhat confusing by different nomenclature. Equating Eiffel deferred classes with Java "interfaces" may make sense, for example. (Not sure as I'm not a Java expert.) But in terms of the Ada/Modula idea of interfaces (which is the context of this discussion - separate interface and implementation), deferred classes are not the correct analogue. For example, consider an effective class which inherits only from effective classes. There is no deferred class in this situation, so you obviously can't use one as an interface. But, clearly, the class *does* have an interface and we see it exists as the short form. I dismiss as nonsensical the notion that a deferred class can be the analogue in one situation and the short form in another. Also, this example shows that it's false to claim that deferred classes can do all that separate interfaces (or short forms) can do. Something that may further help to cement the difference is to consider that a deferred class has a short form and hence has an interface in the Ada/Modula sense. If the deferred class itself is an interface, how can it also have its *own* interface? This would be a meta-interface - a nonsensical concept. The fact that it *does* legitimately have an interface suggests that it isn't an interface in the first place in the Ada/Modula sense. I think the key to getting a handle on this is to recognise that short forms and deferred classes serve different, *non-overlapping* purposes. :>Try thinking along the lines of :> :> a) Ada interfaces correspond to Eiffel short forms, and :> b) Ada abstract types correspond to Eiffel deferred classes. : :Yes, I'm aware that there is an analogy there. Okay. :But I think the analogy is granted too much weight in terms of its importance :to programming. : :It's my position (until further enlightenment :-) that abstract/ :deferred classes can do what separate interfaces do, and more, so :why do we need separate interfaces? A few things here.. First, deferred classes *can't* do everything a short form (or separate interface) can do - see our example above. Second, they serve a different purpose completely unrelated to interface specification (in the Ada/Modula sense) so are irrelevant to the separate interface - implementation issue. Third, if we compare the mechanisms that *are* relevant to this issue - Eiffel short form and Ada package specs - we can see that we don't need separate interfaces. (I won't repeat what others have already covered.) In other words, I agree that we don't need separate interfaces, but disagree with your reasoning. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh