scala has lazy vals, so no problem there :) On 30 April 2010 17:28, Ben Schulz <[email protected]> wrote:
> 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]<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.
