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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: dnew@zloty.fv.com (Darren New) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/10 Message-ID: <5v6mml$jac@newshub.atmnet.net>#1/1 X-Deja-AN: 271406798 References: <5v1gua$fkk@newshub.atmnet.net> <5v2k2n$1cfu$2@flood.weeg.uiowa.edu> <5v4095$h62@newshub.atmnet.net> <5v4g00$pjr@wdl1.wdl.lmco.com> Organization: FIRST VIRTUAL Holdings Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: In article <5v4g00$pjr@wdl1.wdl.lmco.com>, Mark A Biggar wrote: >In article <5v4095$h62@newshub.atmnet.net> dnew@zloty.fv.com (Darren New) writes: >>In article <5v2k2n$1cfu$2@flood.weeg.uiowa.edu>, >>Robert S. White wrote: >>And it's trivial to write a script that takes the short form of an Eiffel >>class and checks it against the CM'ed short form. If you forget to run >>this, you can have a $1 fine. :-) > >If you are going to do this (have the short form exist as an actual >separate configuration item) then all the supposed advantages of having >only a single file just went up in smoke. Not at all. You still have the advantage that the specification is "in your face" while you're editing the implementation, and hence less is likely to get overlooked. You also have the advantage of not needing to do that for small projects, or for helper modules that are private to a single other module. You still have *all* the advantages. You also have the advantage that your tools might be simpler to write, and you have the advantage that your public postconditions and private postconditions are in the same place when you're working on the thing that's concerned with both. You just get told when you change the spec by mistake. What advantages of having only one file for both spec and body do you think you lose with this approach? > You might as well have sparate >spec and bodies. I just told you how to kludge it given you have inadiquate CM tools, kind of as an existance proof that you don't *lose* anything by having spec and body in the same file. I certainly don't think this is a preferred approach. Personally, I think the preferred approach would be an editor that would recognise whether a class is "frozen" or not and simply not let you edit the part that's frozen. You can insert postconditions, but not delete them, unless they're not public postconditions, for example. The ISE tool already disallows saving of an editted class file that's syntactically invalid, so it's not like it's particularly difficult to conceptualize how to do it.