kirk wrote: > Peter Becker 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. >> > and that is the responsibility of the sub-class, not my mother! > > My problem is that I am too pessimistic to believe that people will be happy with me telling them it's all their fault for not reading the FM (or JavaDoc in that case). Particularly if it is a third party that got hurt by a subtle bug introduced by someone subclassing String without obeying the contract. And bugs due to broken immutability assumptions tend to be subtle and hard to debug since the time between error and failure can be arbitrarily long.
It's the same category as having hashCode() depend on mutable elements: you put something in a collection, much later you change it, even later you try to find it in the collection and it is not there anymore, so the results of your application are wrong (which is IMO the worst type of error, even worse than data loss). That's why IMO this way should have never been taken for the hash structures, but it's too late now. If you trust people to get this right all the time, then it is ok. But I don't -- I've screwed that one up myself once before and I wouldn't promise to never do it again. I guess it really depends on what you want. You seem to have a priority for flexibility, while I want to know things are done and good and will never turn an ugly head on me. I think both things can be valuable, but if you prefer the flexibility you might want to reconsider your choice of language. Fortunately the Java ecosystem evolves into a world where different styles are possible. Peter --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
