copy came in 2.8, it only became possible once named and default parameters had been implemented.
On 29 April 2010 22:01, egervari <[email protected]> wrote: > 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]> > <javaposse%[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]<javaposse%[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]<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.
