On 10 May 2010 11:38, Wildam Martin <[email protected]> wrote: > 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. >
I think not! If you change the hashcode of an object in a structure then you create the scenario that your object is now in the wrong bucket. There's every chance that a subsequent check for membership will fail, even though your object really is still in the container. It's a very nasty bug to have to track down... > 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. > > You'd be surprised. I'm sure that many developers once felt there would be only rare situtations where they needed objects, or threads. It takes time to truly appreciate any new paradigm, but once you do it's impossible to not see it being useful almost everywhere. > > > 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. > > An object's identity in this case is all that which distinguishes it from another instance of the same type, so basically any non-volatile state. it's not just some arbitrary name or clsid property. > > > 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. > > To stay performant, well-designed immutable structures rely on lazy copying and will reference large sections of the structure being copied. In this way, the inefficient copying of large chunks of memory can be totally avoided. For example, one common implementation of a list is to represent it as a head element plus a tail list an element can then be prepended by creating a new list with that element as the head and the existing list as the tail. This is very efficient, and existing users of the original list don't have to deal with unexpected changes. Similar designs exist for trees, maps, queues, etc. > > 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. > > FP removes boilerplate and matches the program structure more closely to the underlying domain logic. This can only help *improve* readability, testability and maintainability. > > > 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. > > Dealing with functions in the manner we were all taught at school is hardly "unconventional", nor do I think it's hype that when I call a function I prefer for it not to muck about with the parameters I supplied. > 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. > > Not sure I understand your point here > > > 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). > > Nobody said that anonymous classes are inherently bad. Just that they're often used to encapsulate the behaviour of a single method, an approach that can be made even cleaner by simply manipulating that function directly and dropping the surrounding boilerplate. Many of swing's Listener classes are a verbose poor-man's alternative to true first class function objects. > > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
