EiffelStudio 6.4

by Manu (modified: 2008 Dec 17)

We just released EiffelStudio 6.3 and are already working on the next 6.4 iteration. EiffelStudio 6.4 is a maintenance release toward a full adoption of the ECMA standard. Some of the changes in ECMA require a change in our libraries. Unfortunately some changes are making the libraries not backward compatible.

To avoid a major rewrite of your code, we will ensure that the new version of the compiler will still be able to compile the 6.3 libraries. That way when 6.4 is out, you do not have to upgrade your code right away although there will be a good incentive to do so.

The list of changes are:

  • use of alias for specifying operators in place of infix and prefix.
  • prevent export of the copy, deep_copy, twin, deep_twin routines from ANY.
  • use ~ operator in place of is_equal.
  • change the postcondition of {ANY}.is_equal to enforce that it can only hold if both objects have the same type.
  • making all our libraries void-safe.
  • {ANY}.generating_type to return an instance of TYPE [like Current] instead of STRING.

Because they are breaking changes, maybe we can pack as many breaking changes to avoid having more breaking changes in releases right after 6.4. One of them is to use NATURAL where a non-negative INTEGER is expected. You can vote for that change here.

If you have other ideas of changes that has been discussed in the past and that are not in this list, feel free to post a comment.

Happy Eiffeling!

Comments
  • Simon Hudon (16 years ago 19/12/2008)

    It seems like good changes but I'm not sure I understand why we would want to prevent the exportation of copy, deep_copy, twin and deep_twin. They seem pretty useful.

    Simon

    • Manu (16 years ago 19/12/2008)

      Currently some objects cannot be duplicated. For example a FILE object can be duplicated today because `twin' is always available, but if you do so, don't be surprised to get an exception.

      So not exporting them in ANY, let you decide when it is ok to duplicate an object. This will make some existing libraries more robust in this area.

      • Franck Arnaud (15 years ago 9/1/2009)

        Bad design for ANY

        It sounds like a bit of a bodge. The original bug is to have copy etc in ANY, they should be in a separate class like COPIABLE inherited by classes where it makes sense.

  • Peter Gummer (16 years ago 20/12/2008)

    Why ~?

    I agree these will be improvements. The only one I don't understand is using ~ instead of is_equal. I thought that ~ was just an alias for is_equal, which means (I think) that it wouldn't break any existing code. Obviously there's something I don't understand. Could you explain this one please?

    • Manu (16 years ago 20/12/2008)

      ~ can be seen as an alias to `is_equal' but it is more complicated than that. Per the ECMA spec it is more equivalent to "a.same_type (b) and then a.is_equal (b)". This ensures that no catcalls occur at runtime. The breaking change is that now comparing FILE_NAME with STRING will always yield False, whereas before it would have been True with a harmless catcall (i.e. not reported by the runtime catcall checker in EiffelStudio).

      In EiffelStudio's code, we had so far to change about 20 cases where a comparison that used to return True now return False. Not too bad for 6400 classes and more than a million lines of code. It does not mean that for your application it will be that painless.

      • Peter Gummer (16 years ago 20/12/2008)

        The only uses of FILE_NAME in our project are in EiffelStudio libraries, as well as CONSTANTS_IMP which is generated by EiffelBuild. So I don't think this change will affect us at all.

    • Franck Arnaud (15 years ago 9/1/2009)

      Good riddance for 'equal' as well

      Hopefully ~ also deals with the Void case and is a good riddance for the 'equal' trouble (it's either a permanent systematic catcall if you consider the type of //other//'s like to resolve to ANY, or a typing monstrosity if you consider it to resolve to the dynamic type of //some//).

      The sign allocations are a bit upside down unfortunately: it should be the other way round, I think ~ should be reference equality and always False for expanded types, while = should always map to is_equal. Might have been harder to migrate (and even then, having a warning for use of = with reference type might catch the few cases, I don't expect reference equality is purposefully used that often, actually have a bit of trouble thinking of any example...).