This 'you don't mother other developers' bullpucky needs to stop, now. It's not about mothering other developers, its about having a programming language that adheres to the principle of least surprise, and having a programming language that is relatively easy to debug and test for.
If strings might be mutable, even if there's a contract out that states: "Ensure that all subclasses of string are immutable", you lose all of that. It's not trivial to ensure that any class is immutable. If strange and utterly incomprehensible* things happen when you break this rule, you have a programming language with arbitrary voodoo. For much the same reason, trying to debug this problem is a vague exercise in chasing down heisenbugs. Utterly untenable. The 'right' answer is two-fold: 1. A way to say: This class is immutable (the property sticks around even if you extend it). but as I've explained countless times before, that's not as easy as it sounds. It's still the right answer, granted, but it's not one of those things where you go: "Huh, how could Gosling and friends have been so STUPID? It's such a simple little thing to add! sjeesh!" 2. java.lang.String should have been final regardless of having way to say: Immutable. However, the CharSequence interface needed to get more attention and be the default. String implements it, but so do many other things, including a non-final but immutable variant that includes properties (of the type: "I am url-encoded", "I am http- encoded", "I am xml-encoded", "I am unvetted user input", and all that jazz. These objects contain actual Strings, the immutable and final kind, under the hood. *) knowing how the JVM works internally is not something your average programmer is supposed to need to comprehend, so you must assume they don't. On Feb 23, 2:44 pm, Alexander Snaps <[email protected]> wrote: > On Mon, Feb 23, 2009 at 8:29 AM, Peter Becker > <[email protected]>wrote: > > > > > > > kirk wrote: > > > Peter Becker wrote: > > > >> kirk wrote: > > > >>> [email protected] wrote: > > > >>>> On Feb 17, 6:15 am, Alexander Snaps <[email protected]> wrote: > > > >>>>> On Sun, Feb 15, 2009 at 7:13 PM, Reinier Zwitserloot < > > [email protected]>wrote: > > > >>>>>> I mark any immutable class final, because if it isn't, then you > > can't > > >>>>>> rely on its immutability (any subclass is assignment compatible and > > is > > >>>>>> not neccessarily immutable!). > > > >>>>> While I tend to agree with marking "type" classes as final, I don't > > believe > > >>>>> that a class being immutable is reason enough to mark it final. > > > >>>> If it's not final, it probably isn't immutable. Take java.io.File. > > >>>> Please. > > > >>> Marking a class as final is a whole different ball game than marking a > > >>> variable as final. For example, marking String as final was a HUGE > > >>> mistake IMHO. It prevented people from making some very useful > > >>> extensions. It's also responsible for a lot of code bloat. I'm not > > >>> against making a class final. That said, to do so because of the need > > to > > >>> mother other developers shouldn't be one of them. > > > >> If String wouldn't be final, then its immutability could not be > > >> guaranteed, which would mean you > > > > final class doesn't mean the value is immutable, it means that the class > > > cannot be extended. > > > I'm aware of that, but if you don't put the "final" there even if you > > write a perfectly immutable class yourself, you can still not assume > > that all instances of it are immutable since subclasses might break that > > assumption. So if you want an immutable class, then you have to > > > (a) make sure you write it immutable, and > > (b) make it final. > > I think you only make it final to "mother other developers", as Kirk said. > And I don't see this as a good enough reason... Besides there's always ways > to break something if that is what you want. Sadly also if that's what you > don't want. Constraining people all the time for their "best" is a scary > thought to me, even in software development. > My point is, it's not because a class is not marked as final that all class > extending it will break its immutability either! > > > > > And that's how the String class is done. A proper language concept of > > immutability would be much nicer, but it's not what was done. > > > Peter > > -- > Alexander Snaps > <[email protected]>http://www.jroller.com/page/greenhornhttp://www.linkedin.com/in/alexandersnaps --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
