Re: the benefits of immutability

["Michael St . Hippolyte" <address@hidden>]

On 2003.08.30 11:15 Vadim Nasardinov wrote:
> Michael St . Hippolyte wrote:
>
>  > Equality in Java is inherently non-transitive regardless of
>  > subclassing, because if a and b are objects belonging to different
>  > classes then a.equals(b) and b.equals(a) are in general calls to two
>  > separate methods that don't necessarily have anything to do with
>  > each other.
> 
> I am not sure I understand what you mean by "inherently
> non-transitive".  You cannot possibly mean that no "equals" method can
> ever be guaranteed transitive, for surely it can.
[...]
> If you meant to say that equality comparison across proper class
> boundaries can be fragile, even if both objects share a common
> supertype, that would be hard to argue with.  That's not a problem
> with Java though -- that's a problem with OOP in general.

Yes, it's the cross-class equality comparison I'm referring to.  But
it seems to me it's more a problem with types in general than with 
OOP in particular.  Any typed language that chooses to allow equality
comparisons between values of different types faces the same problem:
who gets to decide whether the values are equal?  Apart from 
primitive types, Java lets each type decide for itself.  But another 
approach is possible: convert the values on each side of the equality
to a common type (strings, for example) and perform the comparison
on the results.  This approach has its own problems (the conversions
might be inefficient, the comparison may not yield the intuitively
correct value for some types, etc.) but at least it would guarantee
consistency.

>  > what precisely are the difficulties in subclassing an externally
>  > facing class?
> 
> Have you read the example I cited earlier:
> http://courses.dce.harvard.edu/~cscie160/EffectiveJava.htm

Thanks for the reference, I missed it the first time.  As I see it,
in the example it uses to make its argument (InstrumentedHashSet) 
the real culprit is not inheritance but mutability.  This is also
true of the various Circle examples in this thread.  I would be
curious to see if anyone can come up with a similar example 
showing broken behavior when functional restrictions are in place,
i.e. objects are immutable and methods are side-effect free.

The second point, about base classes acquiring new methods over
time, is more clearly a consequence of implementation inheritance.
But in a sense this is also a mutability problem: if you change
the definition of an interface (by adding methods to it, for 
example), you shouldn't expect the implementations of it to
continue working correctly.  This is a legitimate criticism of
OO, since it tends to mask such problems, but at the project 
lifecycle level rather than the program level.

Michael