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: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/08/28 Message-ID: #1/1 X-Deja-AN: 268752247 Sender: news@inmet.camb.inmet.com (USENET news) References: <01bcb389$24f579d0$1c10d30a@ntwneil> Followup-To: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel X-Nntp-Posting-Host: houdini.camb.inmet.com Organization: Intermetrics, Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-28T00:00:00+00:00 List-Id: Neil Wilson (nobody@nobody.com) wrote: : Tucker Taft wrote in article : ... : > In my experience, separating the spec and body physically is : > extremely advantageous, and the need to have redundancy between : > the spec and body is an important feature in a multi-person : > project, not an "inconvenience." In Ada (and to some extent in C/C++ : Then do it. This is what fully deferred (or even partially deferred) : classes do in Eiffel. You can even lock down the specification by providing : only the Precompiled version to your implementors (or more simply lock out : the deferred class file using file permissions). One can always argue both sides of an issue like this. 1) Our language forces you to separate spec and body, and that is good. 2) Our language allows you to separate spec and body, but doesn't force you to, so that is good. Perhaps a more relevant question is what style "real" programmers adopt when they use the language, and how this affects the productivity, maintainability, readability, etc., of code built in that language. Note that the Eiffel folks argue exactly the opposite when they talk about "purity" of OO languages, saying that Eiffel *forces* you to put everything in a class, and that is good, whereas the Ada folks say that Ada *allows* you to only use tagged types, but doesn't force you to, so that is good. Similarly, Eiffel forces you to only have exception handlers at the top-level of an operation (which never seemed "good" to me, but perhaps because I don't understand the full argument in favor of this requirement), whereas Ada allows you to place exception handlers as locally or globally as appropriate. In general, language designers have to choose carefully between where they "force" something on the programmer, and where they simply support something. Furthermore, when more than one approach is supported, they have to choose whether one is made significantly easier or more convenient than the other. This is because the rules of the language have a subtle effect on the style adopted by the programmers. It is certainly not zero effect, but it of course is not overwhelming, in that design approaches, past history, etc., all have an effect as well. However, as far as separation of spec and body, I believe many people who have used Ada over the past 15 years believe that this separation "enforced" by Ada was perhaps its most fundamental contribution to programming style. Given that belief, it is very surprising (at least to me) to see some languages moving away from this separation, and only "allowing" it (and sometimes requiring you to work a bit harder and restructure a bit to do it). It is possible that the time for "forcing" this separation is past, but based on my recent use of Java in a multi-person project, I don't think so. The Java "interface" type and "abstract" classes are nice, but the fact that spec and body are merged in most Java classes, even given tools like "javap" and "javadoc" to extract the interface, doesn't substitute for separate spec and body. The hand-written Ada package spec (or even C header) remains a far superior interface document for a given abstraction than is anything I have seen extracted by a tool. The result of extraction by a tool typically ends up getting some but not all of the comments, and the various operations are not presented in necessarily a helpful order, or with any useful higher-level organization. Basically, the extraction tool tends to tell you what an abstraction "is" or "does", rather than what it is supposed to do, and why. When trying to decide whether a given implementation is correct, without that separate human-written spec, it is much harder to evaluate. One is simply stuck trying to evaluate internal consistency, rather than consistency against a separate human-written spec. As an example, look at the "javadoc" produced for the Java standard API. It gives you the facts, but almost nothing more. I suspect that if someone had been "forced" to write a separate spec for each of these classes, there would be something more "specification"-ish there (i.e. what the routines are supposed to do, in words). : Neil Wilson (neil at aldur dot demon dot co dot uk) : Aldur Systems Ltd, UK -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA