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: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: rodemann@mathematik.uni-ulm.de (Joerg Rodemann) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/12 Message-ID: <3418ea2b.0@news.uni-ulm.de>#1/1 X-Deja-AN: 271815627 References: <34167245.0@news.uni-ulm.de> <34170F21.EE560045@munich.netsurf.de> 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-12T00:00:00+00:00 List-Id: Joachim Durchholz (joachim.durchholz@munich.netsurf.de) wrote: > Joerg Rodemann wrote: > > How do you prevent that the implemented class derived from an abstract > > specification class can add public methods to those mentioned in that > > abstract class? > Why should I want to do that? > (I could think of some situations where such a restriction might be > useful, but these are rather exotic.) > In what ways is the Ada way of doing that useful? Because this is the essence of the spec/impl concept in languages as Ada, Modula, the older Oberon dialects. The spec is a _complete_ specification of everything that is exported. Well, in Ada this might be a bit obscured by the fact that the full type and some other things have to be mentionened in the 'private' part of the spec. But at least I understand the reason for this decision and can life with it. On the other hand: I never understood, why Wirth switched from the two file variant to a all-in-one solution. Sure, it makes sense if you take into account the whole Oberon environ- ment --- they have some really astonishing features --- but I still think the language itself lost an important thing. (And there where lots of points I did not like that environment also. But that's a different story.) Well, since it was mentionened by someone else: one thing as important as a complete spec of a package/module (perhaps class/interface) is in my opinion a list of those things that are imported. Of course, if the language is completely class oriented there are no name ambiguities but I often liked to know what packages are directly relevant to a specific package. This often gives an insight-at-a-glance what mechanisms are used. To return to the spec issue: IMHO there should be only included those things that are important to the spec. The body might have a much longer 'IMPORT' list. Regards 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