Re: the benefits of immutability

[Dan Sugalski <address@hidden>]

At 4:15 PM -0400 8/18/03, Seth Gordon wrote:
>On Mon, 2003-08-18 at 08:50, Vadim Nasardinov wrote:
>>
>>  The problem is not that you can't add methods safely.  The problem is
>>  that it is too easy to add them unsafely  One of the String's stated
>>  invariants is its guaranteed immutability.  The only way to make sure
>>  this invariant is *never* violated is to prevent subclassing.  Thus,
>>  true immutability also requires finality.
>
>Object.equals() has a number of stated invariants, too (e.g.,
>transitivity), but they're documented, anyone who overloads the method
>is responsible for following those invariants.  Why can't the
>immutability of String objects be handled the same way?

Because I expect that the Java compilers cheat unmercifully when 
faced with String and StringBuffer objects--since they're final and 
hence non-subclassible, the compiler, and more importantly the 
optimizer, can know *exactly* how they behave and cheat appropriately.

Not that I'm arguing that this is the right thing to do (I would and 
will, I'm just not right now :) but I expect this is why.
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk