On Wed, 30 Apr 2003 at 21:12 GMT, Dave Thomas wrote:
> To be honest, I'm not sure anyone can comment on alternative approaches 
> without knowing the context: what is the problem that's being solved.

I am simply writing my own addressbook editor (as an exercise and
because I am dissatisfied with existing programs). I thought I'd store it
in a file and make a nice Addressbook class that allows me to access that
data without worrying about where it is saved and it what format.  It
should be re-usable so that other people who want to write their own UI
interface to my addressbook can do so using this class instead of
parsing the file. The addressbook will also support internal iterators
and a sophisticated search mechanism (? la mutt).

> So, I'd have a method in Contact that changes an immutable Contact into 
> a mutable one. 

By 'changing into' you mean create a new instance right ? (Methinks we
would be in trouble if an immutable contact could magically become
mutable in the hands of a client.)


> For simplicity I'd also have AddressBook set itself up as the backing
> store for Contacts it creates.  That way you just have to write
> 'contact.save' rather than carry both the Contact and AddressBook
> objects around throughout your code.

That looks very practical but it does induce strong coupling of the
Addressbook and Contact class. Once we go in that direction I don't see
why I shouldn't stick with my original (fully mutable) implementation
where contacts callback on the addressbook when they get a request to
change.
Besides: what would happen if you call #save on a contact and the
addressbook refuses the save because there's already an entry with that
name ? Wouldn't it be better if the Contact consulted the addressbook as
soon as the duplicate name was entered ? (and not after all sorts of
other attributes have been set on the contact)

From everyone's silence on the freeze-your-contacts alternative I
assume it is more of a hack than a design solution.



Greetz,
- Simon


-- 
There are 10 types of people in the world... 
those who understand binary and those who don't.