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: doylep@ecf.toronto.edu (Patrick Doyle) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/08/30 Message-ID: #1/1 X-Deja-AN: 269124417 X-Nntp-Posting-Host: skule.ecf Sender: news@ecf.toronto.edu (News Administrator) References: <33E9ADE9.4709@flash.net> <5u3dne$c20@gcsin3.geccs.gecm.com> <34057115.D4D7713@stratasys.com> Organization: University of Toronto, Engineering Computing Facility Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-30T00:00:00+00:00 List-Id: In article , Simon Wright wrote: > >>From an Ada user's perspective, I believe that the point being made is >that the interface specification and the implementation of that >interface need to be managed separately. They should be separate >configuration items. The overall cost of an interface change is much >larger than that of an implementation change, in general. IMO, having separate interface and implementation files for the same package simply reinforces the somewhat antiquated notion that an implementation has only one interface. In fact, by Ada, they must have a one-to-one correspondence. It has been pointed out that abstract (ie. deferred) classes can do the same thing with greater flexibility. >We tend to think that it'll be easier to manage this if the two things >are in different files. Certainly. The solution I've seen proposed is to create an abstract class for the interface, and freeze it; then work on concrete implementation classes for that interface. Seems to me you can get the same results. >Clearly it would be possible to include a check at handin that the >extracted interface hadn't been changed without permission (for all I >know Eiffel implementations do this already!) You could even imagine >an environment where the interface specification parts of a >normally-checked-out source unit were in fact read-only (I'm thinking >of something like the Rational Delta environment here). > >If you use different files, the effect comes about with far less >effort. That's very true. I guess what I'm trying to say is that languages which combine all code for a class (package) in one file can still do this with abstract classes. This simplification of the language and the development process comes at no cost in flexibility or capability. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca