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: 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/01 Message-ID: #1/1 X-Deja-AN: 269325173 Sender: news@syd.csa.com.au References: Reply-To: nospam@thanks.com.au X-Nntp-Posting-Host: dev50 Organization: CSC Australia, Sydney Newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1997-09-01T00:00:00+00:00 List-Id: Patrick Doyle wrote: :In article , :Don Harrison wrote: :>Neil Wilson wrote: :> :>:Darren New wrote in article :>:<5u2fhb$4t7@newshub.atmnet.net>... :>:> I think people are complaining that one of the missed goals is :>:> "the ability to administratively freeze the interface while :>:> allowing editing/completion/bugfixing the implementation." :>: :>:This is acheived using deferred classes.. :> :>I disagree. Deferred classes are more like Ada abstract types, IMO; short forms :>are more like Ada interfaces. BTW, I meant flat-short form here. : The point is not how analogous they are. Sorry, I disagree. If we're to compare Eiffel and Ada in any meaningful way, finding analogues *is* the point. In particular, we're after the mechanisms in each language that deliver the same functionality. :The point is that freezing interface while altering the implementation can be :achieved using deferred classes. Sure, you *could* use it that way in some specific circumstances but it would be misusing the mechanism, IMO, because they fulfil different roles. The *purpose* of deferred classes is to capture high level abstract design which is made progressively more concrete *through inheritance* by replacing deferred features with effective ones. An additional role is to facilitate polymorphism. This *design* role is mirrored pretty much exactly (minus the encapsulation) by Ada's abstract tagged types. In comparison, the purpose of Eiffel flat-short forms and Ada package specs is to provide a client's *view* of the exported features of a class. This view exists irrespective of whether or not the class's features came about through inheritance and irrespective of whether polymorphism is possible. Something which may help to see the different roles is to consider the situation of an effective (concrete) class inheriting from another effective class (and no deferred classes). Where's the interface? Clearly, it exists only in the flat-short form. BTW, I've taken "completion" in Darren's post to mean actually implementing, as opposed to stubbing. It's true that on the design side, deferred features get effected but I assume that's not what Darren meant. The issue of stubbing highlights an advantage of the Eiffel approach. If an Eiffel system is compilable, it is also executable because all effective features will at least have a stubbed body. Due to the fact that Ada's interfaces are separately compilable, it's not uncommon, early in development, to have to create temporary (usually stubbed) implementations for other developer's packages in order to produce an executable. Although it's fairly mechanical to do so, it's still an inconvenience. The same can be said of the maintenance aspect of redundancy in Ada specs and bodies. I, personally, find it a pain to have to keep the two in synch. Also, if the client produces the stubbed body, as is often the case (because the owner is busy doing something else), the stub is less likely to reflect the semantic properties of the module - for example, by returning non-representative values. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh