The real trick is that: - When cloning an object, it's only a shallow clone, you're not making a bitwise copy of the entire structure!
- Even then, all you're actually copying is the top-level references So imagine the structure Character - Inventory - - Sword - - Potion - Stats - - health - - mana - - xp - - ... - ... and furthermore imagine that those are all case classes. When the character sips from the potion you can then do: def sipPotion(c : Character, numSips: Int) = c.copy(inventory = inventory.copy(potion = potion sip numSips)) with Potion.sip being a function that returns another (immutable) potion object having fewer sips remaining. Naturally you'd have to expand on this in the real application, where Inventory would likely be a Map and the sipPotion function would also have to take some identifier to specify *which* potion, but the principles remain unchanged. I can even picture much of the game being modeled like this; as functions that take a character object as the input and return it with any necessary changes made. On 29 April 2010 13: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]<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.
