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/10 Message-ID: <34170E26.5385DE6D@munich.netsurf.de>#1/1 X-Deja-AN: 271684327 References: X-Priority: 3 (Normal) Newsgroups: comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: Tucker Taft wrote: > Eiffel seems to have foregone even > this bit of declaration-before-use -- there seems no need to > declare the importing of one class prior to using it anywhere > inside another. There are two ways to "import" another class in Eiffel. Variant 1 is inheriting a class. Inheritance links are declared right at the start of a class, so here we have (incidentally) a rather strong "import before use" policy. Variant 2 is using a class, by declaring a parameter or local variable of that class. Eiffel does not have an import clause in that case at all! This isn't even a disadvantage because an Eiffel module can contain only one class (in fact there are no modules beyond classes in Eiffel). Say we have a declaration feature dump (x: CONTAINER) is... so we know x is of class CONTAINER. There is no module CONTAINER is in, so we don't need an import clause to tell us (or the compiler) where to find CONTAINER. If I remember correctly, Ada import clauses are also used to resolve name clashes, but that's unnecessary in Eiffel, too: anything in CONTAINER will be used via x, so we always have a qualified call of the form x.something which automatically provides the necessary context. Note 1: Note that x is much shorter than CONTAINER. If an Eiffel "module" is so pervasive that typing the name everywhere becomes a nuisance, we can choose entity names that are as short as we like to access these features. In Ada, if we have a name clash, we're forced to type the full module name wherever a clashing name is used (at least that's what I remember, corrections welcome!). Note 2: Inheritance gives access to the imported features without a need for qualification, so here the possibility for name clashes exists. In Eiffel you must rename such features in the inheriting class (which is useful if the features are exported - inheriting two features with the same name does not mean they are the same). Regards, Joachim -- Please don't send unsolicited ads.