I think you're oversimplifying, Kevin. 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.
But take your VAT example. If I have an object that represents, say, the current state of the finance rules for a point-of-sale system, VAT might as well be mutable. It has no concept of time other than 'valid right now'. On the other hand, in a database entry, 'timestamp' is undoubtedly part of a sale. And THEN the correct model for VAT (and almost everything else) HAS become immutable: At a certain point in time, the VAT was X, and the VAT on Jan 7th 1989 in Country Y will always be X no matter where or when we are, hence, immutable. The date API also isn't broken strictly for immutability reasons. That's because timestamps ought to be stored as (immutable) longs, and the date/time APIs used only to calculate new ones; effectively Calendar is a builder. It's API certainly looks like a (badly written) builder. On May 9, 2:30 pm, 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 > > Patently ridiculous, of course. Numbers are immutable, 17.5 will always be > 17.5 and never 15. What changes is the reference! If you think in pure > object-oriented terms then some variable 'vat' can start off pointing to the > 17.5 object and later be changed to point to the 15.0 object. > > So how about dates? Does it make any more sense to state that: > may 5 = september 22 > > Again no, but the Java data API allows exactly this to occur. > It's especially fun when it happens across threads... > > So a slightly fictional example here, but close enough to the real world > that I think it makes the point. > > - 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) > > - ... > > *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. > > 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. In general, it's good advice to make > everything immutable that possibly can be, and change is achieved by taking > a copy of objects and making the update as the copy is taken. This issue > goes far beyond dates and is critical for being able to reason effectively > about concurrent systems. > > On 9 May 2010 01:30, Peter Becker <[email protected]> wrote: > > > > > > > On 09/05/10 09:21, Wildam Martin wrote: > > > [...] > > >> I shudder at the > >>> thought of mutability in some of this, the API effectively states that > >>> you > >>> can change May 5th to become September 22nd; > > >> Who cares? - Really: This is something, a professor at university may > >> mutable > > >> have a philosophic problem with - in the real world nobody had a > >> problem with that before the functional and immutable hype. > > > 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. The classic > > example: put a mutable object into a hash structure and change properties > > that affect the hash code. > > > Any object that mutates its identity is a bug waiting to happen. Lack of > > immutability is real problem in the real world. It makes reasoning about > > code much, much harder and allows for bugs that are hard to see. > > > And BTW: Yes, it can make sense: Let's have a deadline on May 5th that > >> is moving to September 22nd. Why shouldn't it be valid to change that > >> date? - Not every date is a birthday. > > > 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. > > > [...] > > > - They continue to be willing to add proven new techniques and patterns to > >>> the platform and C# language. Such as dynamic lang support, FP > >>> constructs > >>> via LINQ, sensible property handlers, delegates (method handles), > >>> closures, > >>> etc. Java prevaricates over all of these. > > >> Guess what: I didn't miss any of that stuff in the last 15 years of > >> development - so a) it can't be something real essential. And apart > >> from that I currently don't see a particular situation currently where > >> I would use any of that. > > > Nothing beyond Turing completeness is essential. Yet we still do it. > > > 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. 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. Particularly in test code I find having predicates > > and a map function for collections much to useful to avoid the friction FP > > style creates in the Java world. > > > 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. > > > 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]<javaposse%2bunsubscr...@googlegroups > > .com> > > . > > 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 > athttp://groups.google.com/group/javaposse?hl=en. -- 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.
