Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ucsd!hub!eiffel!bertrand From: bertrand@eiffel.UUCP (Bertrand Meyer) Newsgroups: comp.lang.eiffel Subject: Re: BASIC TYPES Message-ID: <251@eiffel.UUCP> Date: 20 Feb 90 06:14:10 GMT References: <1864@clyde.concordia.ca> Organization: Interactive Software Engineering, Santa Barbara CA Lines: 45 In <1864@clyde.concordia.ca>, marcap@doyle.cs.concordia.ca (Marc Pawlowsky) voices concerns about basic types and their use as parents in inheritance. I essentially agree with his observations. To reconstruct the sequence of events: - In the original language design, as reflected in ``Object-Oriented Software Construction'', four types (INTEGER, REAL, BOOLEAN, CHARACTER) were treated specially, i.e. outside of the object-oriented context. The reason was twofold: a concern for performance; and a feeling that ``everyone knows about integers and booleans anyway'' and that using the OO framework to handle them was overkill. - After a while we recognized that it was in fact unpleasant to have this ``magical'' status for basic types, and that (thanks to expanded types, infix/prefix operators and constrained genericity, among others) it was indeed possible to have a fully consistent type system, elegantly covering basic types as well as user-defined types, without necessarily sacrificing implementation performance. As a result, the basic types are treated as ``quasi-normal'' in the release available since last summer (2.2). Internally, however, they are still handled specially so as to guarantee a high level of efficiency (3 + 4 is theoretically a routine call, but few Eiffel users would want it to be implemented that way!). In fact, this part is one of the trickiest in our implementation as we try to reconcile elegance of concept with efficiency of implementation. Furthermore, there are still many carryovers from the original implementation. For example (as pointed out by Norman Shelley and others) having a function ``abs'' (absolute value) for integers and a different one, ``rabs'', for real numbers, is anathema to the object-oriented approach. I am not particularly proud of that one (which, fortunately, will be easy to correct; it just escaped our attention). As we continue improving and generalizing the implementation, we will strive to achieve the degree of generality desired by Mr. Pawlowsky and other writers (and Eiffel users such as ourselves). Although we would like INTEGER et al. to be conceptually treated exactly like any other class-based expanded types, we cannot promise that ALL restrictions will be lifted soon. We want Eiffel to remain implementable with a very small performance overhead over something like C, and some tradeoffs need to be made for this goal to remain realistic. -- -- Bertrand Meyer bertrand@eiffel.com