Thanks so much Kevin for this. That's a pretty neat way to do it. I wasn't really aware of a copy() method. Is this one in scala or is that one you write yourself? I don't think I see it anywhere. Just .clone() (which I am not sure does anything for case classes or not).
This is going to be hard though because while an rpg looks simple, it's actually amazing how complex everything can get. Like, you equip a helmet that adds 20% max health and +15 strength, and you have an armor that adds +30 max health, and yet a shield that adds +2.5 health per level. Even still, you could have a passive skill that gives +10% max health per skill point in the skill tree ;) The dude deallocates some skill points and starts unequipping items, and things get really complicated quickly ;) I already have a great mutable design to handle all the cases fantastically (it's so super clean and sexy), but immutability would really complicate that design. I'll try this pattern out for some new classes that are not nearly as complicated to see how it works. If I like it, I can always go back and upgrade the rest of the code in a piece meal fashion. Thanks Kevin! On Apr 29, 9:17 am, Kevin Wright <[email protected]> wrote: > 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 > 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.
