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=-0.3 required=5.0 tests=BAYES_00,INVALID_MSGID, YOU_INHERIT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Thomas Beale Subject: Re: Design by Contract Date: 1997/09/03 Message-ID: <340CDE84.6ACC@invest.amp.com.au>#1/1 X-Deja-AN: 269638421 References: <33E9ADE9.4709@flash.net> <34023BC4.2781E494@eiffel.com> <3402d123.0@news.uni-ulm.de> <3402DA6A.C4444E46@calfp.co.uk> <3402e51d.0@news.uni-ulm.de> <3402E8C9.3384D976@calfp.co.uk> <34050F3C.5A3A@invest.amp.com.au> <5u61qa$e23$6@miranda.gmrc.gecm.com> <340CA8E5.2A6A@flash.net> Organization: AMP Investments Australia Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-03T00:00:00+00:00 List-Id: Ken Garlington wrote: > > Robert Dewar wrote: > > > > Can we hear from someone who has used Eiffel with, say, either Clearcase > > or Continuus, and has cleanly solved the problem of giving different > > access rights for spec and implementation changes. > >.... > Personally, given that you can (a) mimic Ada specs in Eiffel with > deferred classes, (b) mimic Eiffel combined specs/bodies in Ada with > a decent editor (and, in the case of GNAT, with gnatchop), and > (c) mix and match deferred and concrete operations in both languages, > I don't see a huge difference between the two languages in this > area. Bad CM will defeat either language's approach... Unfortunately this approach equates to introducing SPECIFICATION v IMPLEM (or SPEC/DESIGN/IMPL, or more levels if you want) as one of the dimensions of inheritance. Eiffel for example has no problem with extensive MI; the problem is that the traits of SPEC v IMPL are orthogonal to all the rest of the things you are modelling - they are not (shouldn't be) in the model at all. To see this, just imagine an MI situation: C inherits A and B. You potentially want SPEC and IMPL versions of all these classes: SPEC_A SPEC_B ^ ^ | | SPEC_C ... now where to put the IMPL_A etc classes? You can't really do anything sensible, because denoting classes as "specification" or "implementation" is a process concept. Next week you may want to change it, but if it's in your inheritance model, you're in big trouble. Now, IMO, achieving the required result requires three things: - a repository representation of programming artifacts (normally classes, or patterns in e.g. beta), where representation is fine enough to allow syntactic elements to be controlled separately. E.g. method name, Result type, arg names and types etc etc. - a CM system which can be told to manipulate the contents of this repository in the same way files are manipulated by the (fairly pedestrian) CM systems of today. I.e., treat selected groups of programming artifacts as configurations in the CM sense. - The combined CM system/repository must be capable of understanding dependencies between artifacts so that a change to a specification-level artifact (e.g. a result type) reports the affected implementation-level artifacts. Conversely, an attempt to alter an artifact already constrained by anpther artifact must be stopped with a sensible indication of why. Such "understanding" requires a language tool e.g. an Eiffel or ADA compiler. This allows you to say that certain aspects of an individual class are "specification", and cannot be changed in that class (achieved by CM ownership, permissions etc), or in inheriting classes (achieved by the language tool). But since we are controlling parts of classes (not whole files), there is no problem with an implementor adding implementation details to a class containing "locked" specification details. Actually, in the case of inheritance, you can do something very nice. Let's say you have a class feature address:LIST[ADDRESS_ITEM] -- eiffel which you want to "lock" as specification. Inheritors should be allowed to do: address:LINKED_LIST[ADDRESS_ITEM] -- conformant redef but not (say): address:SET[ADDRESS_ITEM] -- non conformant The language processor in the repository will allow you to define such a constraint, by simply saying that the descendant class must compile. In summary: a repository whose elements are transparent (therefore processable) by language tools, and whose same elements are also transparent (therefore maniplatable) to CM or VC systems is required; further, the CM system must be able to use the language processing tool to define and test dependencies. A simple example of this would be a constraint that forces all descendants of class C to have the same short-form as that of C. - thomas beale