Simon Vandemoortele wrote:

> That's certainly a simple solution to my problem. It's my impression
> though that Dave would go more toward the immutable/mutable +
> transaction concept. I am guessing this is for extendability, robustness
> reasons and I am quite confident this is a good idea. With my limited
> experience however, I am unable to 'see' why; I am trying to envision
> how the mutable solution would limit me in the future but can't think of
> anything. (But then, people with limited experience are more
> shortsighted.)
> 

Actually, if I was writing it for myself, I personally wouldn't do any 
of this. This discussion came about because you wanted somehow to 
differentiate read-only from read-write versions of Contacts, as you 
wanted changes to contacts to ripple through to the backing store. We 
went down the (im)mutable path to satisfy that requirement.

However, that's not the way I'd go. Instead I'd make the objects all 
mutable, and have a 'save' method that stored them away on a change. 
This is what I did last year when I wrote a fairly large web-based 
registration and ordering system in Ruby.


Cheers


Dave