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: doylep@ecf.toronto.edu (Patrick Doyle) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/08/28 Message-ID: #1/1 X-Deja-AN: 268725099 X-Nntp-Posting-Host: skule.ecf Sender: news@ecf.toronto.edu (News Administrator) References: <33E9ADE9.4709@flash.net> <34046FAD.52BFA1D7@eiffel.com> <34048FDC.13728473@eiffel.com> <3404909F.2C67412E@eiffel.com> Organization: University of Toronto, Engineering Computing Facility Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-28T00:00:00+00:00 List-Id: In article <3404909F.2C67412E@eiffel.com>, Bertrand Meyer wrote: > >The goals are clear: I agree with most of these goals, but I have an issue with one of them: > G5. Minimize the programmer's work. In particular > it is crucial to avoid forcing the programmer > to duplicate text. Duplication is almost always > bad, especially with respect to ease of maintenance, > one of the central goals of software engineering. > It also hampers reuse, reliability (when you > duplicate code, you duplicate its bugs, and > the more software you write the more likely > it is that it will include bugs), and ease > of change. Of course duplication is bad, but this is a special case which is not nearly so bad. These, if I understand, are your reasons for disliking code duplication: 1. Too much typing 2. Duplicate code duplicates bugs 3. More code means more bugs 4. Too hard to change Here's why I don't think any of these are serious problems here: 1. The same tools which provide interface files for documentation in Eiffel could provide them for compiler usage in another language, so there is no more typing than in the Eiffel approach. 2. This is true, but is no more a problem than a single bug in this case because if the bug is fixed in one place, the compiler will force us to fix it in the other place. 3. Certainly, given two independent code fragments, the total expected number of bugs would be greater than that of a single fragment. But in this case, the fragments are not independent: if the implementation (which includes the interface) is bug-free, then so is the interface. If the interface has a bug, then so does the implementation; but this is really one bug as argued in #2. So by adding an interface file, we haven't added any extra potential for bugs. 4. The interface of a class is the part that the rest of the system relies on. Perhaps it should be hard to change. I think there is merit in making a programmer aware that certain changes could have repercussions outside the module in question. So, while true, point #4 may not be a problem at all. Having said all that, I'm not particularly in favour of one method over the other. To me, it seems like a very minor issue compared with the complexities programmers have to deal with. I don't think the one-file-versus-two issue has any real lasting effects on the development process. One last argument... In Eiffel, a short form can be produced for documentation. Why not give the compiler the capability to ensure that the short form matches the code being compiled? And if we do that, aren't we back to the separate-interface-file model again? -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca