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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,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/05 Message-ID: <5upe9k$7he@newshub.atmnet.net>#1/1 X-Deja-AN: 270019679 References: <33E9ADE9.4709@flash.net> Organization: FIRST VIRTUAL Holdings Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-05T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: >Suppose I wanted to change the position from Positive to Natural, because >for some strange reason I decide I'd rather count starting from 0. This >change can't be made indiscriminately, because clients already depend on >certain behavior (count starting from 1). In Eiffel, this would be a change in the `requires' clause of the Remove procedure. This implies a change in the specification of the class, just as it does in Ada. I.e., Remove would change from require position > 0 to require position >= 0 (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?) >But now it's not so obvious how to separate the changes made to the bodies >of the operations from the contract itself. Easy - did the short form change? > By putting spec and body together, the configuration management >tool has to be smart enough to determine which part is the specification of >the routines and which is the body - much more sophistication than a CM >tool that need only treat everything as mere text. I can easily imagine having triggers in CVS at commit time that would generate the short form, compare it to a saved short form, and disallow the checkin of the class if the short form changed. Alternately, it's pretty easy to write a shell script that takes the file you're trying to checkin and checks out the associated "locked" short form, comparing the two appropriately. It doesn't *have* to be integrated into your CM tool if you have a command-line CM tool. Alternately, you *can* use deferred parent classes if your tools are too primitive to handle derived files. >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. >It just seems simpler to have a different text file for the spec. That way >changes to the body can be made with impunity, and the compiler will check >that you haven't changed the contract in any way (because the contract is >kept separate). It's true that treating things as separate files is easier with current tools, but I suspect that's because current tools grew up around primitive compilers. Of course, it's simpler (in the same sense) to have the programmer specify inter-file dependencies as well, as in Makefiles. The fact that current CM tools are better geared towards separate spec and body doesn't necessarily mean that's a good way to go. Obviously, any CM tool written with Eiffel in mind would allow the kinds of things you use separate files for in Ada, just as any CM tool written with Ada in mind allows you to extract the body for a given interface, etc. If you're working on a project large enough that you're actually worried about accidentally changing the spec and not realizing it, you're working on a project large enough to add a macro to generate and CM your short-forms as well. :-) Otherwise, give me a language where I can put all my punch cards in the same box. ;-) >There are probably some Eiffel subtleties that I've missed, but I hope I've >been able to explicate the Ada philosophy with respect to separation of >spec and body. Eiffel's philosophy is to not make the programmer do the same thing twice, and to put relevant information together. Hence, the programmer puts the spec and implementation in the same place, and the tools pull it apart as needed. I can easily see Ada's style causing a problem if (for example) the interface declares an offset to be a Natural with a comment saying "when passed zero, this means the end of the list". (Probably a stupid thing to do in Ada, but it's an example.) In this case, a programmer working on the implementation might not see the comment in the spec and may think the offset starts at zero, miscoding the implementation in unobvious ways.