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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: What is wrong with OO ? Date: 1997/01/10 Message-ID: X-Deja-AN: 209017281 references: <5acjtn$5uj@news3.digex.net> organization: The Mitre Corp., Bedford, MA. newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-10T00:00:00+00:00 List-Id: In article <32D53473.4DAA423A@eiffel.com> Bertrand Meyer writes: > The ISE Eiffel compiler performs inlining completely automatically. > There is no "pragma inline" or comparable programmer intervention, > since it is not the programmer's job to worry about whether a routine > is inlinable or not. This is a job for a compiler. For some things this works, but Bertrand then says: > (In addition, for an object-oriented language, inlining is only > possible for a routine that is never subject to dynamic binding. > This requires extensive analysis of the software. If the > programmer requests inlining but it is semantically wrong, the > compiler should ignore the request. But then if the compiler is > capable of doing this analysis it should take care of the inlining > too, without bothering the programmer!) This is where the problem arises. If you compile everyting in one big batch, this is possible. But if you don't then the user needs to be able to say: "I don't expect any later subclass to override this method. If I do that (or some other programmer does), I'm willing to take a big recompilation hit." Add to this the fact that a lot of apparently dynamic links in Ada are actually resolvable at compile or link time, and you want the ability to mark methods this way. For instance, you can have a call on a method of a specific type which dispatches to an inherited method which then makes many other calls on methods of the type. If the outer call is inlined, then all the inner calls dispatch statically as well. Often these inner calls are to placeholder routines which contain no code, or to routines which are only a few machine instructions in most static cases. > ISE Eiffel does give the user a degree of parameterization: > a compilation option specifies the size threshold beyond which > a routine will not be inlined. This is measured in internal units > (number of bytecode words), but easy to relate to number of > instructions. This option provides a way to control space-time > tradeoffs. In practice, however, most users are happy with the > default, which inlines small, frequently called routines. Ah, most Ada compilers do this as well. But occasionally there is a big payoff from inlining an otherwise large routine. One case is that you know that it is only called in one place. Another is mentioned above--inlining a "big" routine may result in further automatic optimizations so that the final code is very small. > This automatic optimization is crucial because the object-oriented > style of development, with its emphasis on abstraction, naturally > tends to yield many small routines. With ISE Eiffel, you can write the > software as it should be, not asking yourself all the time "should > I violate abstraction here and avoid writing a small routine because > of the effect on performance?"... Same in Ada. > You just leave this kind of concern to the compiler. ("Inline" > pragmas would be almost worse here, because you would have to > perform yourself the analysis of what is inlinable and what is > not. The incrementality problem is particularly nasty: change a > single line somewhere in a large system, and a routine that was > inlinable, far away in the software text, now becomes > non-inlinable! This kind of systematic, exhaustive work, > error-prone when done by humans, is what computers are for.) This is why the Ada pragma is ADVICE. If the compiler can no longer follow the advice, it has to go back and recompile things. (Technically, the compiler can just tell the user which items are obsolete, but all Ada compilers I'm aware of do this automagically or through a make facility.) The important thing is that pragma INLINE can affect speed, executable size and/or compilation time, but it can never affect correctness. > I also think that the Eiffel view of "separation of specs and > implementations" is more sophisticated than Ada's one (which I > assume is the one Robert Dewar has in mind), but that will be the > topic for another debate... If a classical debate, one well worth following. But please don't frame it that way. It is not a feature war. Both Eiffel and Ada had models in mind when the languages were developed, but the set of models supported in each case is richer, and overlapping. AFAIK, the "pure" Eiffel and Ada models are supported in both languages. However, there are design models that work in Ada but not Eiffel and vice-versa. Also there are features in both languages that make impure versions of their design models much easier to work with. For example, in the previous discussion, we have seen a case where the user wants to limit a generic to one with comparisions. Ada can follow the Eiffel model: generic type Foo is new Comparable with private; ... But more normally in Ada this will be done as: generic type Foo (<>) is private; with function ">" (L,R: Foo) return Boolean; ... As I pointed out, this is because the Ada type model sees classes as sets of types all having a specific set of operations. Therefore it is more normal (in Ada) to specify a class by specifying the required operations. The fact that a class is hierarchical is expressed by/visible because of the available type conversion operations. Two types are members of the the same class if an object of one type can be explicitly converted to an object of the other, or both can be converted to a third type. (To make that "if only if" is complex since I can't specify the third type to class mapping in less than a page. For example all discrete types can be converted to _universal_integer_ by 'Pos.) In a hierarchical class all objects can be converted to / passed as a parameter of the type at the top. In Eiffel, even though the actual concept of class is very similar, the model is explicitly hierarchical. (You can implement the Ada number class in Eiffel by adding explicit conversions which break the hierarchy.) As I said, it is not that it is not possible in Eiffel, it is more that it is not done. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...