Re: Dr. Myere Addresses ECMA Standard and Backward Compatability

[email protected] wrote:
	Of particular interest is the last paragraph where backward
	compatability is addressed at a high level.
	
	http://www.eiffel.com/general/monthly_column/2005/April.html
	
Let me quote that paragraph.  It's actually the second-to-last.

    As always, backward compatibility and the stability of user
    investment is at the center of our concerns (after all, we are major
    Eiffel users ourselves, with a huge investment in the technology,
    and a constant concern to preserve that investment).  Plainly
    speaking, no one wants to break existing code.

Yet as the draft stood a couple of weeks ago, it did exactly that.

    It is essential to remember here -- for example when you start
    reading the description of the new mechanisms -- that even when a
    change looks incompatible with the earlier version this doesn't mean
    it will make code stop from working.

But it DOES mean that you CANNOT convert smoothly from the old style
to the new style one step at a time.  It means you have to convert each
class in one big bang, and that's bad.

    The compiler should and will provide both the old and the new forms;

Meyer IS in a position to make this promise for his own compiler,
but if the standard does not *enforce* this he is *not* in a position
to promise it for anyone else's compiler.

    there's almost no case in the language definition for which they
    can't be both accommodated.

Then why aren't the both accomodated IN THE STANDARD?
(Not that this claim is actually true.)

    You will be given ample time to update your code, several years if
    needed, although we think you'll like the new mechanisms enough to
    want to take advantage of them.

Again, he may possibly be in a position to promise this for his own
compiler, but NOT for anyone else's.  He could *ONLY* promise this for
other Eiffel compilers IF the standard required it, but it doesn't.

    Migration aids will be available to support this process.

They will be desperately needed.  However, the standard says NOTHING about
such aids, and because the standard says nothing about the old features,
there is no guarantee that migration aids from one vendor will interpret
old features the same way that migration aids from another do.

In short, the article doesn't actually *address* backwards compatibility
at all, but simply makes vague promises that there is no problem.

By the way, I am astonished that the draft has been submitted to ECMA
already.  When I looked at it two weeks ago, it was in a VERY rough state.
The conformances rules, for example, were incomplete and inconsistent, and
a major new facility (void-safety) was very sketchily described indeed.
And there was NO usable description of ANY of the core classes, not even
by reference.  (Note the word 'usable'.)