One of the key differences between mutable and immutable records is how far you can take (typesafe) initialization. Mutability easily allows for circularity while immutablity does not or only to a very limited degree <http://www.haskell.org/haskellwiki/Tying_the_Knot>. On the other hand this freedom requires a null-like value and makes non- null fields very hard to verify. (Spec# manages it with Delayed Types <http://research.microsoft.com/pubs/67979/delayed.pdf> which is a reasonably simple approach to take but does not allow for phazed initialization).
With kind regards Ben On 29 Apr., 14:41, egervari <[email protected]> wrote: > How many of you are currently programming in a hybrid language such as > Scala? > > I'm finding it difficult to make things immutable. While I am > definitely using more immutability than I ever have in the past, I > don't think it's practical for some applications. > > For example, I am making a game right now. While I can kind of see how > to make it immutable... I'm not sure it's entirely desirable. There is > a lot of state in a game, especially a complex one. > > Right now, classes that are immutable are things that don't have a lot > of nested structures, or things that have case class semantics. For > example, a Potion of healing that heals for 200 health is a good > example of an immutable object. Once it's consumed, you can just throw > it away. > > Also, various parts of the game will have use actors, so I make sure > any of the objects that need to be passed from actor to actor in the > messages are immutable. If they aren't going to be used as messages, I > prefer mutability instead. This is backwards of what people have been > saying to do... but I find it makes things much simpler. > > The hardest part of keeping everything immutable is large classes with > collections. To make them fully immutable, you have to clone > everything on every operation. > > Let's say you a character in an rpg game and you change their name. > Bam, you gotta clone all fields and return a new character. This is a > gigantic pain in the ass. It feels bloated to do it over and over, and > it is a maintenance havoc. > > I'm thinking back to some systems I have done in the past, where I > have 130-150 domain objects. How do we make those immutable? If you > have a customer... and you change a line item on an invoice... you'd > have to re-create the entire object graph if you were working with the > root customer object. > > How have you been wrestling with immutability/mutability in your > programs? What patterns/principles have you been using to decide? How > far have you gone to the immutability end? > > -- > 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.
