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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: doylep@ecf.toronto.edu (Patrick Doyle) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/05 Message-ID: #1/1 X-Deja-AN: 269948552 Sender: news@ecf.toronto.edu (News Administrator) References: X-Nntp-Posting-Host: skule.ecf Organization: University of Toronto, Engineering Computing Facility Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-05T00:00:00+00:00 List-Id: In article , Don Harrison wrote: >Patrick Doyle wrote: > >:In article , >:Don Harrison wrote: >:> >:>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. Ok, let's boil this down to two questions: 1. What is the purpose of short forms/Ada interfaces? 2. Why can't deferred classes accomplish this purpose? >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. Well, before you dismiss it, let me make a case for a very similar situation... If you want to look at the whole interface of a class, you can use Eiffel's "short" tool to extract it. What the short tool produces is code which is, effectively, the deferred class which would correspond to the effective class in question (except that it is missing the word "deferred" in certain places). So if you want to specify an interface, use a deferred class. If you already have an effective class and want to see its interface, you can simply look at its deferred parent class (if it was designed with one) or, failing that, the "short" tool can rig one up for you. >Also, this example shows that it's false to claim that deferred classes can do >all that separate interfaces (or short forms) can do. I haven't yet seen you describe just what an interface or short form *does*. >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. I think this still makes sense. The short form is only missing the word "deferred" (and some other trivial syntactical niceties) in the appropriate places. Add these back in, and the resulting deferred class is exactly the same as the original class. Thus, the class *is* its interface. I could create a DoyleShort tool which produces the same thing as the Short tool, except with the "deferred" etc. in the appropriate places. If I follow your reasoning, the Short tool's output would then correspond to an Ada interface, while DoyleShort's output would correspond to an abstract package (is that the term?) in Ada. Yet the only difference is the word "deferred". How can such a trivial difference make the two concepts orthogonal? >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. Unless the interface is identical to the class itself. >I think the key to getting a handle on this is to recognise that short forms >and deferred classes serve different, *non-overlapping* purposes. I'm ready to accept this if someone would just tell me what these purposes are. >: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. I'm sorry--it's been a long day--but I didn't see you explain what short forms or interfaces *do* at all. >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. Well, thanks for your patient attempts to persuade me :-) but I'm still a bit puzzled... -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca