Re: the benefits of immutability

["James Y. Knight" <address@hidden>]

On Tuesday, August 19, 2003, at 04:09  PM, Perry E. Metzger wrote:
>> String, Boolean, Double, Long, Float, and Integer are immutable, 
>> unless
>> you've got a different notion of mutability than what I've seen.
>
> Sure, but my point is that everything in sight (see StringBuffer,
> which is pretty obviously mutable) was made final by Java's designers,
> on the premise, presumably, that they knew everything you would ever
> want such an object to do. I'm sure this provided them with teeny
> improvements in optimization (but given the fact that the stock JDK
> barely has any optimization at all that's ignorable) and with teeny
> improvements in their ability to force certain interfaces to be
> "Secure" for some definition of "Secure", but it is also a royal pain
> in the ass.

As pointed out above, almost "everything in sight" is a core class 
which is immutable, thus giving good reason for being final (security). 
I object to "teeny improvements in their ability to force certain 
interfaces to be "Secure" for some definition of "Secure"". I think 
it's rather more fundamental than that.

>> Even if these weren't declared final, anybody reading code where they 
>> were
>> subclassed would think that something weird was going on -- who 
>> subclasses
>> String?  Why would you want to?
>
> In this case, I was using Java's types to represent types in a higher
> level language I was interpreting and wanted to add some protocols to
> all said types to ask them to do various things, like evaluating
> themselves. It would have been very convenient. I was forced to use
> much less convenient techniques.

Aha! Breakthrough! Here is the *actual* problem. I suspect given this 
problem, you would have been sorely disappointed even if you could 
subclass String, because it would be quite irritating to convert all 
the java.lang.String types that other people's code has created into 
"YourStringSubClass" types to get the extra methods. Not very 
convenient. So, you don't really even WANT to subclass String, you want 
to add a 'category' (terminology from smalltalk) to it! You want ALL 
Strings, no matter who created them, to have your extra methods.

Now *this* is something that can be done securely, and I agree that 
java should allow it. Perhaps you should start campaigning for it to be 
in the next version.

There are two key differences between subclassing and adding a 
category, in my imagined implementation: 1) the category cannot change 
currently defined methods or add new fields, only add new methods (and 
the new methods don't even get access to private members), thus 
ensuring that security is not broken, 2) a category adds the methods to 
the base type (String) instead of adding them to only to a new subclass.

I believe there has been a proposal/paper on adding categories in java 
in the past, but I don't recall where I saw it. Maybe someone can dig 
it up. Actually, I think AspectJ could do this, if support for it were 
integrated into the runtime. Maybe around Java 1.7 we'll finally see 
this show up. ;)

James