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/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 -~----------~----~----~----~------~----~------~--~---
