On Sun, May 9, 2010 at 02:30, Peter Becker <[email protected]> wrote: > Oh yes. I have seen bugs based on using mutable (and mutating) objects were > clients made assumptions about immutability, or even worse: not making the > assumptions themselves but using data structures that do.
In the beginning of a disaster there is always a shitty assumption... > The classic > example: put a mutable object into a hash structure and change properties > that affect the hash code. Of course, if you change an object propery the hashcode has to be recalculated. I think this should be clear also for a beginner developer. Please don't misunderstand me: Immutability may make sense, but if I make everything immutable and then continuously have to recreate objects for new if I need to change a part of the object then this strategy is simply a mismatch. In my programs I have only rare cases where immutability makes sense. YMMV. > Any object that mutates its identity is a bug waiting to happen. Lack of > immutability is real problem in the real world. I agree with you that an object's id should be an immutable thing. But this is just a property of an object (yeah, even if an object itself) like a string for instance holding a CLSID or whatever. This is not what I understand from people talking about immutability - they mean this on a higher level. I thought of your argument with higher bug probability and I can imagine immutability reducing bug probability. That said, I would put a higher priority to other things like performance. > There is a difference between a date as a property and a date as an > instance. You might again claim that is "philosophical" or "academic" (in > the negative senses of those words), but I will again claim that it is of > relevance for writing easy to understand and safe code. If you change the > date of a milestone, you assign a new date to the milestone, you do not > change the nature of the old date. The latter would affect everything else > that uses the same date. I would say this is like the glass half full or half empty. You could see it as the date is changing or as a new date gets assigned. Both views are possible. When implementing a program I would use that view that results in the most performant solution. If I need to copy a whole object structure I would go the the mutable way just for the sake to avoid unnecessary work. > I have plenty of use cases for using FP in Java, up to the point where I > sometimes do, despite the fact that it creates a lot of syntactic noise and > some confusion in co-workers. For me the question would be if the benefit from FP outweighs the confusion. Don't forget also that generations change, co-workers change and young people follow older ones. A programming language - or the paradigms you use - should consider this. A program should be readable as easy and by as many people as possible. Otherwise it will not be very maintainable in the long run. And also think that you might have difficulties in reading your own code afte rnot looking at it for a long time and now maybe slept only a few hours the night before need to fix a bug quickly. > But once you get the idea it becomes easy to > understand a huge class of straightforward solutions to problems that are > otherwise hard to solve. I am sure there are particular scenarios where particular (maybe "unconventional") bring you an awesome benefit in getting to your solution. But I am also sure that applying a new/modern/hype paradigm at every point creates more problems than it solves. Quite everything I saw rising in the last years, like XML, Web Services and whatever - got modern (everybody wanted that to write that on the package of the software) and applied anywhere. > If you want FP-free Java you have to take "Strategy" out of your pattern > box, and also remove ActionListener and any similar interfaces. The people > who ask for closures mostly want a nicer solution to exactly this class of > problems. OK, everything can be exaggerated. Let's say: Everything where it fits. BTW: Regarding the anonymous classes: I found the Visual Editor in Eclipse for instance producing very bad code. I prefer 100 times the way how matisse in NetBeans does it by default (you can even configure it to use anonymous classes). On Sun, May 9, 2010 at 14:30, Kevin Wright <[email protected]> wrote: > Why immutability matters. > Imagine you have a financial system, it includes VAT calculations at some > point, using VAT at 17.5% > vat = 0.175 > then, at a later point in time, the government changes the VAT rate to 15%, > possibly in response to some sort of "banking crisis": > 0.175 = 0.15 > The value 0.175 is made to equal 0.15 Very strange conclusion... > Patently ridiculous, of course. Numbers are immutable, You are wrong here - the point is: The VAT is mutable! Even if a 1 itself is an immutable 1. But the latter is a metaphysical background here and not of interest. > - You have an array of date objects, call it "datesInSeptember". This array > is used to populate a selection dialog on a form or webpage somewhere. > - A user selects "September 22nd" from these dates to use as a project > deadline. > - Later on, another user attempts to use the 22nd from the same array for a > totally different purpose > - Later still, the first project deadline changes, so the date object is now > updated to, say, 1st November. > (remember, this is still the exact same object still held in the > "daysInSeptember", and used by the second user) You are mixing things here: Within the list the dates should be mutable - if I want to have let's say 5 proposals for dates in september I want to be able to change that list. Then when I use the date in different other objects then THEIR according PROPERTIES need to change according to my selection. This is what I would see as the practical and logical solution for such a use case. In that case the object properties all get a copy of that date object (whether it is immutable or mutable either doesn't make a difference then anymore). > *this* is why immutability is so important. It's not about stating that a > value once chosen can never be changed, it's about changing that variable by > having it refer to a new object and not mutating the original reference in > place, especially when that value may be used elsewhere. The design mistake here is to use references to objects accross logical boundaries and to avoid object copying in general. While languages such as Scala (as from my understanding - I am not a Scala developer) use a lot of implicit object cloning. I find that there is no problem with mutable objects as far as you know when to create a copy instead of just using a reference. > and for this reason, the Java date API is badly broken. We fortunately have > JodaTime which *does* make all date values immutable, so there is a solution > for this particular problem. I think, that Java does not very well fit with your preferred way of thinking. Getting back to the original topic: Good to get an overview of many languages, but focus on the one or two that you can be most productive with. On Mon, May 10, 2010 at 10:57, Reinier Zwitserloot <[email protected]> wrote: > I think you're oversimplifying, Kevin. Or "overphilosophying". ;-) > Yes, sure, you need to make defensive copies here and there if things > are immutable. And, sure, dates be as immutable as strings and > numbers. Maybe dates should be handled like strings - I can understand this in the meantime. I use dates mostly as strings and just convert them to date objects where necessary, so somehow I notice that I created this "immutability" here without even noticing. -- Martin Wildam -- 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.
