Wednesday, August 23, 2006


Equality of expanded objects

David Hollenberg noticed that EiffelStudio 5.7 is accepting the following code fragment. Although the compiler emits two VWEQ warnings, the fragment compiles and runs (printing "False" twice):
   print (3 = True)
   print (a = b)
David asked (on the EiffelStudio Developers mailing list):
Is this really allowed by ECMA-367 or does the compiler have a problem? If ECMA-367 allows this, should it?
Bertrand Meyer replied:
This is permitted by the ECMA language definition. The matter was discussed at length in the committee over several meetings; the deciding point was that it's not quite realistic to enforce the earlier rule that the type of either of the arguments should conform to the other. This prevents comparing objects of types C and D, both of which conform to both of A and B, but not to each other. Then variables of these types can actually be attached to the same object.
The definition of x = y for reference semantics (see 8.21.3 in the standard) is that x and y are attached to the same object. For expanded semantics as in your example, it's that they are attached to equal objects, where equal objects must have both the same type and the same value.
In the end it was felt that one should be able to ask a question, without first asking the question of whether one may ask the question.
I must admit that I did a double-take at the above sentence: isn't that what static typing is all about?

Bertrand continues:
There could have been a special rule for the expanded case -- since we know in advance that there is no conformance and that the result will always be False -- but this seemed to complicate the rules too much.
As a general rule I am wary of relying on warnings but this seems to be a valid use for them: an indication by the compiler that things are not necessarily wrong but that the construction is unusual and needs to be checked.

The question of equality is really not a typing issue. Static typing says (more or less): when there is a variable declared of type T, then any value dynamically stored in T will always provide the services promised in the definition of T.

The point is: you can always compare objects. Given an apple and a pear, it should always be possible to ask: are they the same? The answer will of course be: no way - except of course, if we manage to breed a mixture of pear and apple.

So, I believe that the Eiffel language has been cleaned up, though the acceptance of such a comparison will prevent some programming errors to be discovered through static verification.

As already described by Bertrand, there is really no other way of doing it that pays respect to the fact that we have multiple inheritance and polymorphism.

On the other hand, the fact that is_equal in ANY is still defined with 'like current' is a major design mistakes. It violates all the insights that we have developed for the '=' operator. It should be defined as 'is_equal(other:ANY)'.
In SmartEiffel, the signature is is_equal(other: ANY).
INTEGER = BOOLEAN is now just a warning.

The end of static typing.

And if the committee was in doubt, why not make it a setting? 100% of all Eiffel programmer will turn it on, believe me.
If I understand it correctly, the error condition should be the following: comparison of two non-conforming, frozen types (all expanded types are frozen).
The end of static typing??

I think not.

I got caught on a similar issue yesterday using ES 5.6.1218.

Class A includes a routine that returns a desendant of A, B.
C is also a descendant of A, but does not conform to B.

In the routine, I added a post-condition:

new_object: Current /= Result

and gelint flagged a VWEQ error, against the possibility of C /= B.

In effect, this is saying that a post-condition will be a tautology for certain descendants only. Clearly this is not a real error.

Note that ECMA has dropped VWEQ, and a jolly good thing too!
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?