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: rodemann@mathematik.uni-ulm.de (Joerg Rodemann) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/10 Message-ID: <3416ad14.0@news.uni-ulm.de>#1/1 X-Deja-AN: 271309144 References: <33E9ADE9.4709@flash.net> <5upe9k$7he@newshub.atmnet.net> <5utag9$o6s@newshub.atmnet.net> Followup-To: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Organization: University of Ulm, SAI, Germany Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: Darren New (dnew@zloty.fv.com) wrote: > 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. What about having pre- and postconditions in the spec file? At least for predconditions this should be possible. Postconditions may depend on internal and thus private class information, so there might be a problem. Realize also that not everything from the Ada spec is repeated ind the body: type or task declarations for instance. > 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. Oh, really? I can garantuee you at list in C this is very likely to happen: all you have to do is to (ooops) delete the return type --- voila. Why not use an int return type instead? And thanks to implicit type cast you'll never know until you start wondering about those very strange looking results your program produces. :-) At least that's one of the advantages of C++ over C: it is not so likely this will happen when you wrap everything in classes. > 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. I'd like to agree that --- if you fiddle around with large logical expressions or something it may take some time until it's correct in both places. Again I wonder if it would be easy to have those pre- and postconditions in a spec file. Or are they often too dependent on class internals? If so how can they describe a contract between a client who certainly should not know anything about the private parts of the class? Well, just an idea... > >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. Hm, I believe the problem is: you may use the QUEUE class as an interface but you might change you opinion later and use it just as a base class. Then you need to write a new spec and the old one is obsolete as an interface. This is not my idea of an interface clients can rely on. If there is a possiblity of freezing the short-form(?) this is more what we are looking for. Yours Joerg -- rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann Phone: ++49-(0)711-5090670 | Flurstrasse 21, D-70372 Stuttgart, Germany -------------------------------+--------------------------------------------- rodemann@rus.uni-stuttgart.de | University of Stuttgart, Computing Center Phone: ++49-(0)711-685-5815 | Visualization Department, Office: 0.304 Fax: ++49-(0)711-678-7626 | Allmandring 30a, D-70550 Stuttgart, Germany