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,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: dnew@zloty.fv.com (Darren New) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/07 Message-ID: <5utag9$o6s@newshub.atmnet.net> X-Deja-AN: 270407738 References: <33E9ADE9.4709@flash.net> <5upe9k$7he@newshub.atmnet.net> Organization: FIRST VIRTUAL Holdings Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-07T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: > >In article <5upe9k$7he@newshub.atmnet.net>, dnew@zloty.fv.com (Darren New) >wrote: > > >>(Hmmm... Nothing would actually tell the clients that they're invalid >>any more, automatically. I suppose the same is true of Ada, tho. Do your >>Ada tools warn you to go fix all your code that references packages >>whose interface has changed since you last editted them? If so, why would >>you think the same couldn't be done for Eiffel?) > >I wasn't trying to disparage Eiffel (which I happen to like); I was trying >to explain to an Eiffel user the rationale for Ada's separation of >interface and implementation. I understand the rationale. I just disagree with it. :-) My point was that since changing the spec means you have to go talk to everyone concerned anyway, I don't see the advantage of putting it in a separate file. >The point I was trying to make (actually, it was Tuck who explained it >better) concerns precisely the issue you alluded to: that changing the spec >can potentially break its clients. The spec is a contract, and it can't be >just changed indiscriminantly. The author of the spec has to go visit the >clients and ask if the change is OK; a negotiation must take place between >spec author and spec users. Agreed. So? Eiffel has specs also, and the specs are separate from the implementation. The only question is whether the spec is in the same "compilation unit" as the implementation. >The Ada model is that the specification is therefore a contract, As in Eiffel. Hence the name "Design By Contract". :-) > to be kept >separate from the implementation. That's the Ada assumption that's a nonsequitar in Eiffel. > The programmer of an implementation has >to assert that his body conforms to that contract. As does the programmer of Eiffel bodies, either with or without abstract parent classes. > The separation of >interface and implementation also allows the contract to be managed >independently of the implementation, using traditional configuration >management tools. There's the rub. My point was, why do you think traditional configuration management tools can't generate a short form from the Eiffel class text and disallow checkins that have changed the spec in incompatible ways? Also, why do you think that a configuration management tool chosen by a group working in Eiffel wouldn't have that capability? I then tried to make an analogy with a configuration management tool (boxes for punch cards) that couldn't handle Ada CM style, meaning that the failure of current tools to be sufficiently flexible doesn't mean we should accept a worse solution in terms of file organization; we should instead make better tools. (Not to be taken to mean that Ada is objectively worse. Its choice to separate spec and body was only worse to those designing Eiffel.) >The Eiffel argument against this model is that it requires the programmer >to write the subprogram signitures twice; this is a fair enough criticism. >However, if you ask an Ada programmer how he feels about this >"encumbrance," he'll tell you it isn't an encumbrance at all, and that he >actually likes the fact the interface and implemenation are in separate >files. That's fair too. I'm not saying Ada is wrong. I'm just saying that the expressed reasons for saying Eiffel is wrong are unfounded. I think both methods have good points and bad points. On the other hand, Eiffel specs are (I think) more expressive and complete than Ada specs, including preconditions, postconditions, invariants, and so on, and these things get inherited in sufficiently complex ways that just looking at the spec on paper is unlikely to be particularly informative anyway. Hence, typing all the assertions etc in two separate files is going to be a nightmare. Note that the Eiffel spec, while intermingled with the implementation, is clearly separated. It's unlikely that an Eiffel programmer will change the spec and not realize it, any more than it's likely a C programmer will accidentally change the return type of a function and not realize it. >No one can argue with the philosophy that "a programmer shouldn't have to >write something twice, because if he does so he may make an error, so >there's inconsistancy." But this is a weak argument against Ada's >separation of spec and body, as the compiler checks that that subprogram >signitures in the spec and body match. But there's lots more delarations in Eiffel than Ada, I expect. I thought the only things that go in the Ada header files are essentially type declarations, not code for invariants, yes? (No, I don't know Ada. :-) Admittedly, Ada's type declarations are much more powerful, but not as powerful as Eiffel's assertions. >of the body. In any case, the writing of subprogram signitures consumes >only a tiny fraction of the programmer's time. And I expect in Eiffel it consumes a fairly large amount of the time, since the signatures (counting assertions) is a fairly large part of the design of the program. >Eiffel programmers, here's some advice: choose your battles more carefully. >If you argue against something that isn't that big an issue for the >programmers to whom the issue applies, then it tends to make all your other >(potentially good) arguments suspect. And if you argue that Eiffel should be as easy as Ada in Ada's strong points, while ignoring Eiffel's strong points, you wind up with odd misunderstandings. :-) >I agree; that's the argument exactly. How would freezing the spec of the >abstract superclass help you do change control on the subclass? I don't >think that solves the problem of how to manage the specification of an >abstraction. This was addressed by someone else. Briefly, there's two abstract classes. One for QUEUE and one for BALKING_QUEUE, and two implementations. --Darren