Submitted by Berend de Boer on Thu, 12/18/2008 - 06:47.
What does it imply? I still compile code with SmartEiffel 1.2r7, yes there's nothing out there that can compile small programs in a few seconds. And it doesn't take up 500MB per program. I've dozens of such small programs. So if it doesn't effect compiling with earlier Eiffel compilers, I'm ok.
Submitted by Emmanuel Stapf on Thu, 12/18/2008 - 17:21.
Your comments have nothing to do with the question. Personally I do not care about SmartEiffel, they are out of the picture by not following the ECMA specification. We are interesting in moving forward and sometime it requires breaking code for the better of course.
Submitted by Emmanuel Stapf on Fri, 12/19/2008 - 16:28.
The new library code will be incompatible. So regardless of your compiler, as soon as you start using the new library with its new interface, you won't be able to use your new code against the old libraries.
Now the code of EiffelBase being affected is not compiler specific, so you could apply the same kind of changes on older version of EiffelStudio.
Submitted by Bernd Schoeller on Mon, 01/12/2009 - 08:53.
As off-by-one is very common in indexing situations: there seems to be no exception when I underflow (e.g. 0 - 1) in NATURAL. With INTEGER, the invariant "count >= 0" captures these errors, but this will go away when INTEGER is replaced by NATURAL.
Submitted by Colin LeMahieu on Tue, 07/14/2009 - 22:54.
I'd like to see it just changed to INTEGER_64. An underflow doesn't necessarily mean an error condition and with an exponential increase in count, worrying about one more bit wouldn't matter. Having the count of a different data type than indexes would mean a lot of truncating conversions converting between them.
If we were to change in EiffelStudio 6.4 the query `count: INTEGER' to be `count: NATURAL', will that be ok?
Comments
What does it imply? I still
What does it imply? I still compile code with SmartEiffel 1.2r7, yes there's nothing out there that can compile small programs in a few seconds. And it doesn't take up 500MB per program. I've dozens of such small programs. So if it doesn't effect compiling with earlier Eiffel compilers, I'm ok.
Your comments have nothing
Your comments have nothing to do with the question. Personally I do not care about SmartEiffel, they are out of the picture by not following the ECMA specification. We are interesting in moving forward and sometime it requires breaking code for the better of course.
Although I completely agree,
Although I completely agree, the question is still valid: what are the implications for compiling with older compilers? None?
The new library code will be
The new library code will be incompatible. So regardless of your compiler, as soon as you start using the new library with its new interface, you won't be able to use your new code against the old libraries.
Now the code of EiffelBase being affected is not compiler specific, so you could apply the same kind of changes on older version of EiffelStudio.
Compiler errors are better
Compiler errors are better than run-time assertion violations. Thanks for consulting about this breaking change.
Underflow errors
As off-by-one is very common in indexing situations: there seems to be no exception when I underflow (e.g. 0 - 1) in NATURAL. With INTEGER, the invariant "count >= 0" captures these errors, but this will go away when INTEGER is replaced by NATURAL.
Thus, the switch seems to be somewhat dangerous.
The idea is that we will
The idea is that we will also have overflow or underflow detection implemented too which will be the equivalent of the `count >= 0' assertion.
Actually we were thinking to go from INTEGER (aka INTEGER_32) to NATURAL_64. This would provide enough capacity for years to come.
I'd like to see it just
I'd like to see it just changed to INTEGER_64. An underflow doesn't necessarily mean an error condition and with an exponential increase in count, worrying about one more bit wouldn't matter. Having the count of a different data type than indexes would mean a lot of truncating conversions converting between them.