One of the cornerstones of my 2d game programming since I've seriously programmed games has be my Tuple2 class, which I've slowly added methods to until it has become pretty durn useful. Objects often have a Tuple2 as their location, and keep a single reference throughout their entire life. I'm now wondering, prompted in part by my own thinking, and in part by Item #13 of Joshua Bloch's Effective Java, "Favor Immutability," if I should make Tuple2 immutable. If I have a great many moving objects, will it be taxing to make a new Tuple2 for every object, every frame?
I've heard it takes forever to grow a woman from the ground
I'm a big fan of making immutable classes wherever possible - or, wherever I see a possible benefit. But I have a hard time imagining a benefit here. Immutability is great for things that aren't expected to ever change, or that rarely change and if they do, you don't need (or want) the changes to be communicated to other threads which may be (accidentaly? unknowingly?) using the same object. (As is generally the case for strings.) But it sounds to me like your tuples will change very frequently -I'm guessing there's little benefit to making them immutable; it probably just makes more work for the JVM. Ask yourself this: how many different threads need to access a given tuple? If the tuple values change due to processing by one thread, do you want the other threads to see the changes? Immutable classes can simplify multithreaded applications, if changes to data either don't occur, or don't need to be shared with other threads. But I'm guessing that you either don't have a multithreaded application, or you need the data changes to be communicated to other threads. In which cases, immutability is no use to you, I think.
Is there something about your application which makes you think immutability would be useful here?
"I'm not back." - Bill Harding, Twister
Joined: Apr 04, 2004
Thanks Jim, that makes a lot of sense. The only advantage I really see is blindly jumping on a bandwagon.