[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the benefits of immutability
On Tuesday, August 19, 2003, at 04:09 PM, Perry E. Metzger wrote:
>> String, Boolean, Double, Long, Float, and Integer are immutable,
>> 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
>> subclassed would think that something weird was going on -- who
>> 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. ;)