alanm@wizard.UUCP (Alan Myrvold) (06/05/89)
In article <150@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: > >Consistency of the type system > > Beginning with version 2.2, Eiffel has a fully consistent type system in >which every type, including basic types such as INTEGER, REAL and so on, >is defined by a class (using the multiple inheritance mechanism). This was I'm a bit confused as to how Eiffel 2.2 is going to provide INTEGER, REAL, et al. as class types, with commutative operations, efficiently, without the ability for the type of the result of a routine to depend on the types types of its arguments. In article <133@eiffel.UUCP>, bertrand@eiffel.UUCP (Bertrand Meyer) writes: (edited for brevity) > (In version 2.2, however, > it will remain possible to assign an integer value to a real > entity, with the expected effect of a conversion. > ... > > expanded class INTEGER > feature > infix "+" (other: REAL_CONVERTIBLE): REAL is > external > integer_addition (other: REAL): REAL language "..." > do > Result := integer_addition (other) > end; -- "+" >... > Here no conversion is required for integer operations. Since REAL_CONVERTIBLE does not inherit REAL, this code fragment seems to violate typing rules. I guess there are two ways to fix this up, by changing > Result := integer_addition (other) to Result := integer_addition (other.to_real) which seems to contradict the statement: > Here no conversion is required for integer operations. Or by disabling the typechecking in the external declaration from > integer_addition (other: REAL): REAL language "..." to integer_addition : REAL language "..." Which forces the external routine to determine at runtime the type of "other" and apply the appropriate operation. Perhaps the compiler will be taking care of all of the messiness, and providing the appropriate in-line code, and if so, how can a class like "complex" be added so that the infix operators work as expected? Does the statement : k := k + 1; Actually convert 1 to real, perform the addition and convert the real back to an integer? And if another numeric class, say "complex" were added to the system, would k := k + 1; convert to complex, perform the addition and then convert back to an integer? Now, if there were overloading .... :-) expanded class INTEGER feature infix "+" (other: COMPLEX): COMPLEX is do Result := other.add(Current.to_complex); end; infix "+" (other: REAL): REAL is do Result := other.add(Current.to_real); end; infix "+" (other: INTEGER): INTEGER is do ... end; Which violates the idea that adding a new class (like COMPLEX) shouldn't force changes in the interface and implementation of a "closed" class like INTEGER. - Alan --- Alan Myrvold 3755 Riverside Dr. uunet!mitel!sce!cognos!alanm Cognos Incorporated P.O. Box 9707 alanm@cognos.uucp (613) 738-1440 x5530 Ottawa, Ontario CANADA K1G 3Z4
belle@skipper.dfrf.nasa.gov (Steve Belle) (11/10/89)
Is anyone out there using Eiffel 2.2? More specifically, is anyone using the graphics library of Eiffel 2.2? I finally received the upgrade and have spent the last few weeks upgrading the Eiffel code I had written using 2.1. This release is a definite improvement, especially in the implementation of menus and buttons. Events are handled in a much more elegant way. There have been episodes of flakiness, however, and I'm not sure what the cause is. Sometimes my application behaves differently each time I run it although I do not make any changes in between runs. Seriously, I can run it once, and it will crash, giving a meaningless error message. I can start the program again, and it runs fine. It's very strange. Anyway, does anyone out there have any comments on Eiffel 2.2 (especially the graphics)? Steve Belle belle@skipper.dfrf.nasa.gov