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,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: Bertrand Meyer Subject: Re: What is wrong with OO ? Date: 1997/01/09 Message-ID: <32D53473.4DAA423A@eiffel.com>#1/1 X-Deja-AN: 208751414 references: <5acjtn$5uj@news3.digex.net> <32D11FD3.41C6@wi.leidenuniv.nl> content-type: text/plain; charset=us-ascii organization: Interactive Software Engineering Inc. mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Date: 1997-01-09T00:00:00+00:00 List-Id: Robert Dewar wrote: > > Bart said > > "You shouldn't bother programmers with inlining. Inlining can be done > automatically by the compiler." > > I don't see this is possible across modules without violating the integrity > of separation of specs and implementations. 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. (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!) 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. 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?". 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.) 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... -- Bertrand Meyer, President, ISE Inc., Santa Barbara (California) 805-685-1006, fax 805-685-6869, - ftp://ftp.eiffel.com Visit our Web page: http://www.eiffel.com or http://www.eiffel.com/noframes.html (includes instructions for downloading ISE Eiffel 4 for Windows)