The basic idea is that if you "insert" an Apple into a collection of Oranges, then you get back a collection of Fruit. Both the new collection and the original are immutable, with the original continuing to be a simple collection of Apples.
This nicely sidesteps a *lot* of problems. Not just thread synchronisation, but also things like the Liskov Substitution Principle. As for allowing mutability then, sure, it can be done. You simply have to clamp down on your types for the mutable subclass (which is fairly standard practice in polymorphism anyway). The mutator methods introduced in the subclass DON'T permit Co- variance, but you're still free to use the inherited methods which will force you back into immutability. Casting around that is theoretically possible. Which is why Haskell purists will tell you that casting is unsafe and a lie (tantamount to reflection hacks). This is also why Scala very purposely made casting so verbose and ugly - you really don't need it if you have immutability and you're using the type system correctly. On Jul 30, 2012 9:30 PM, "Fabrizio Giudici" <[email protected]> wrote: > On Mon, 30 Jul 2012 21:21:08 +0200, Kevin Wright <[email protected]> > wrote: > > In one word: Immutability >> > > In two words: yes and no. Immutability must be pursued as often as > possible, but a general purpose language cannot force it. Lots of developer > around aren't skilled enough to work with immutable-only data. > > PS I'm not sure immutability would solve the problem above, but I didn't > think a lot about it. > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > [email protected] > http://tidalwave.it - http://fabriziogiudici.it > -- You received this message because you are subscribed to the Google Groups "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.
