Monday, June 26, 2006
Farewell INTEGER, REAL, etc
Three months ago, class INTEGER started to disappear from the SmartEiffel development version. You can still declare an entity to be of type INTEGER, but it's nothing more than an alias for INTEGER_32. In the future this may change - for example INTEGER could become an alias for INTEGER_64.
The xxx.to_integer and xxx.is_integer calls have also disappeared. You now need to use sized calls such as xxx.to_integer_32 or xxx.is_integer_16.
Class REAL has also disappeared, becoming an alias for REAL_64.
EiffelStudio is moving in the same direction. In a recent posting to the Es-devel mailing list, Emmanuel Stapf wrote:
The xxx.to_integer and xxx.is_integer calls have also disappeared. You now need to use sized calls such as xxx.to_integer_32 or xxx.is_integer_16.
Class REAL has also disappeared, becoming an alias for REAL_64.
EiffelStudio is moving in the same direction. In a recent posting to the Es-devel mailing list, Emmanuel Stapf wrote:
STRING won't exist anymore, it will be replaced by STRING_8. Don't worry, the compiler will still accept STRING, because our new project configuration will let you decide what you want STRING to be. The same applies to the following classes and I'm also giving you their default meaning:
- STRING -> STRING_8
- INTEGER -> INTEGER_32
- NATURAL -> NATURAL_32
- REAL -> REAL_32
- DOUBLE -> REAL_64
- CHARACTER -> CHARACTER_8
- WIDE_CHARACTER -> CHARACTER_32
- INTEGER_REF -> INTEGER_32_REF
- REAL_REF -> REAL_32_REF
- DOUBLE_REF -> REAL_64_REF
- CHARACTER_REF -> CHARACTER_8_REF
- WIDE_CHARACTER_REF -> CHARACTER_32_REF
If you are happy with the default mapping, then you don't have to do anything, the upgrade will be completely transparent for the Eiffel compilation. Otherwise, you can simply override this mapping and define your own.Emmanuel pointed out a few consequences of such a change at runtime: features 'generator' and 'generating_type' would now display STRING_8, INTEGER_32 etc; also affected would be the INTERNAL class, the CECIL call-in mechanism, and the STORABLE mechanism. Emmanuel writes:
The last one would break a lot of existing applications if nothing is done about it. Indeed when looking for STRING, nothing will be found and thus a retrieval error would be raised. To solve this, we are proposing to do the following: when we cannot find a class, we search a possible mapping in our predefined mapping (the one above). This lookup will be activated by a toggle which is on by default. For newly created storable, the toggle will be disabled upon retrieval (it means that we will change the version number of our independent store format, making new version non-retrievable by old systems).