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.5 required=5.0 tests=BAYES_00,INVALID_MSGID, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII 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: mheaney@ni.net (Matthew Heaney) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/06 Message-ID: #1/1 X-Deja-AN: 270326811 References: <33E9ADE9.4709@flash.net> <5upe9k$7he@newshub.atmnet.net> Organization: Estormza Software Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-06T00:00:00+00:00 List-Id: 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. 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. The Ada model is that the specification is therefore a contract, to be kept separate from the implementation. The programmer of an implementation has to assert that his body conforms to that contract. The separation of interface and implementation also allows the contract to be managed independently of the implementation, using traditional configuration management tools. 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. 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. That this is "manual work better done automatically by a computer rather than manually by a human programmer" is also a fair criticism, but again a weak argument. Many environments will generate the subprogram stubs automatically, and besides, the signitures are small compared to the rest of the body. In any case, the writing of subprogram signitures consumes only a tiny fraction of the programmer's time. For example, when I'm writing a unit, I'll write the spec, compile it, and then use a copy of the spec as the starting point for the body. (To be honest, though, I never write an abstraction in strictly "spec then body" order.) 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. >>The change affects only the Balking_Queue subclass - not the abstract >>superclass. That's why I'm not clear how freezing the spec of the root >>type really solves anything. > >The balking queue is another class, in Eiffel, with its own spec, >etc. I'm not sure I understand the question. Freezing the spec of >Queue solves the problem of changing Queue, not the problem of changing >Balking_Queue. 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. To get random signatures put text files into a folder called �Random Signatures� into your Preferences folder.