You think it would make more sense if, to properly write java code, you really need to be intimately familiar with the vagaries of the JVM itself? You think it would still be acceptable that the requirements for a JVM remain as vague as they are now on how they work internally? You think that back in the day (java 1.0/oak), gosling and company would have had the vision to not add to the spec a large set of chains that would have made our current speedy hotspot compilers virtually impossible to write - given that it is now apparently required as a potential java programmer to know how it all works, and you're supposed to rely on this information?
Just... no. Why don't you elaborate with some examples of what a non-final String class could have brought us? The vast majority of use cases I come up with involve automatic state transitions, where for example a method wants to url-encode everything that comes in, unless its already url- encoded. Therefore, it wants to know if the passed in string has the 'I am URL encoded' property, and if not, run it through another method which turns strings that don't have the 'I am url encoded' property into strings that do have it (by encoding it). At the same time, the way that method uses a string, is to ask for the raw format, which any 'encoded' string knows how to get to, by decoding itself. I don't see how to get this right. Even if string wasn't final, you can't just make a bunch of state-reflecting methods (getRaw(), getEncoded(), isEncoded(), isSafe(), checkForSafety(), etcetera) without getting stuck in enumerating all use cases. Without those methods being on the common superclass (String), how can an encoder do the job of decoding first? See if a string is an instanceof an EncodedString? That's still not going to work unless the core runtime includes the concept of an EncodedString, which still means you have to enumerate use cases. And what of the canonical value of a string? Should an encoded string return the encoded, or raw, version, when used as just 'a string'? It can't throw an exception (The way you're arguing I feel you're going to ask me to back this up, but I'm just going to leave that as an exercise for the reader) - it has to pick one, which is an obvious code smell. Letting separate libraries take care of this job creates confusion and PHP 'magic quotes'-esque fiascos, where an encoded string done with one library, handed off across a module boundary with abandon (the strings take care of themselves, after all!), get encoded again by the other library, screwing everything up. Strings are one of those near-primitives in java: They get passed around all the time across all sorts of API boundaries. There's a lot of potential for strings that track their own state, but just making string non-final doesn't magically solve this problem. In fact, that seems like a bad way to get there from here, or even from java's origin times when you could still make that change without potentially breaking every other line of java code in existence. Then there's stuff like SecurityMonitor and security-conscious applications, like mass-hosted web-apps, where mutating strings can be used maliciously, and the code would have to defensively copy every string. Which goes right back to: Without enforcing immutability, strings suck. On Feb 23, 4:35 pm, kirk <[email protected]> wrote: > Reinier Zwitserloot wrote: > > This 'you don't mother other developers' bullpucky needs to stop, now. > > I'm sorry but historically this was a justification for making the class > final. I agree, it's a bogus argument. Having mutable Strings in > Smalltalk didn't make String un-usable just as having mutable Strings in > other langauges didn't make them un-usable either. > > > *) 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. > > Too bad because that is a tool of our trade and not knowing how it works > is a handicap in my not so humble opinion (when it comes to this subject > but I digress) > > Regards, > Kirk > > > 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/alexa... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
