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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Joachim Durchholz Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/12 Message-ID: <3419B6BF.97B99592@munich.netsurf.de>#1/1 X-Deja-AN: 272449349 References: <5var3e$s63$1@trumpet.uni-mannheim.de> X-Priority: 3 (Normal) Newsgroups: comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-12T00:00:00+00:00 List-Id: Marc Wachowitz wrote: > If you merely import a package, by means of a "with" clause, you > cannot > get any name clashes at all, no matter what's in the package, since > every > reference is qualified with the package name. Well, that's what's *never* necessary in Eiffel. Either you inherit, then you *must* resolve name clashes by renaming (or you can undefine one of the miscreants). Or you use, then you *always* qualify with the entity name (not the class name - the class is already attached to the entity, which must be named anyway). > If you don't like some name, e.g. of a package or a type or a variable > or > a routine or an exception, you can introduce another name for it This is nice. If it was in the original language draft, I forgot about it (and now I think it actually was part of the language then). > (which > may be local, but can also be exported by a package). Even better. Sounds like Eiffel stole that from Ada. > Only if you really call for it, by means of a "use" clause, all the > stuff > exported by an imported package will become visible in the client's > scope, > and thus be a potential source for name clashes (for routines only > where > overloading can't resolve the conflict). Many people don't like > use-clauses, > and some projects don't allow them. I can understand that. In Eiffel such a policy wouldn't be necessary. A name clash is either accidental (then it must be resolved by renaming) or not (in which the clashing actually refer to the same thing, which doesn't need any resolving). Regards, Joachim -- Please don't send unsolicited ads.