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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: Samuel Mize Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/10 Message-ID: <3416C410.DD5@link.com>#1/1 X-Deja-AN: 271300760 References: <33E9ADE9.4709@flash.net> <5upe9k$7he@newshub.atmnet.net> Reply-To: smize@link.com Organization: Hughes Training Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: Robert Dewar wrote: > > <<(Hmmm... Nothing would actually tell the clients that they're invalid > any more, automatically. I suppose the same is true of Ada, tho. Do your > Ada tools warn you to go fix all your code that references packages > whose interface has changed since you last editted them? If so, why would > you think the same couldn't be done for Eiffel?)>> > > The Ada requirement is MUCH stronger. This is not a matter of warnings, > this a matter of legality. A compiler that allowed you to assemble a > program with obsolete components (changing a spec on which you depends > definitely makes you obsolete) would be invalid, and the validation > test suite contains many tests for such things. I believe he's saying that most implementations of Ada don't warn you which other library units your change has just obsoleted. You have to go compile or otherwise check each module and see what's become obsolete. This works with Eiffel too, according to the Eiffel users. In fact, some Ada toolsets DO provide this capability. The Rational environment maintains library units in different states from "text" through "object code has been generated." I believe it has a capability to tell you what other library units depend on a given unit, so you can tell who you're going to screw up if you edit something. Certainly a simple "grep" for "with XXX" can tell you the first wave of dependencies if you edit XXX (that is, it won't give you the transitive dependencies, only the direct ones). If there isn't a similar tool in GNAT, it could easily be built based on the cross-referencer. I suppose one could be built for Eiffel, too. Sam Mize