On Tue, Feb 24, 2009 at 1:45 AM, Peter Becker <[email protected]>wrote:
> > 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. > I think the analogy to the hashCode (& equals) is pretty nice, as indeed it is being violated all the time! At least, in my experience, in many teams I worked on... Though dismissing the approach because of that very argument seems a too weak reason imho. While people tend to believe everything is straight forward with Java (I'm not saying it isn't ;), it still requires a good understanding of _all_ the basics for it actually to be relatively easy. Another example that comes to my mind is threading... How many different home-made cache implementation have you seen on projects? Almost every single project I was on tried to implement such a cache at a point or another. And, especially on projects I've joined later in their development cycle, I've been told: "It works just fine... even in production". Until failures worse than "UI ones" appeared, where "refreshing the page" would not solve the problem (i.e. multicore cpu, maps & infinite loops ;)... Now what would have been the right approach on these issues? Having a different multithreading model? Another hash structure way (as you proposed)? Maybe... yet not to fix (common?) misunderstanding of the platform/language by developers... I really believe it is our duty to get a, at least good, understanding of the platform & language we make a living on as developers... I do hope that with such an attitude we'd also get to much better code bases out there! Constraining developers in too many ways will just have them figure yet more twisted ways to work around these limitations... And people do have imagination out there! So, I will still not mark my classes as final, and will just trust developers extending them to know what they are doing. Besides, training people on those implications while on a team could just lead to better developers, isn't it? Alex > > Peter > > > > > > -- Alexander Snaps <[email protected]> http://www.jroller.com/page/greenhorn http://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 -~----------~----~----~----~------~----~------~--~---
