Path: utzoo!attcan!uunet!mcsun!hp4nl!media01!pkr
From: pkr@media01.UUCP (Peter Kriens)
Newsgroups: comp.object
Subject: Re: Re: How would yo model this situation?
Message-ID: <1475@media01.UUCP>
Date: 30 Oct 90 09:59:29 GMT
References: <17486@rouge.usl.edu>
Reply-To: pkr@media01.UUCP (Peter Kriens)
Organization: Mediasystemen, Netherlands
Lines: 41

> But,
>  what happens to the rope object?  It breaks in two, but each
> piece has most of the characteristics of the original piece (except
> things like someone on the other end, length, ...).
>   The two people can still access their respective rope objects.
>  Is this still one rope object that now mangages 2 pieces instead
>  of one?  (this is simple to do)
>  Or should the rope object mutate?  i.e. break into two distinct
>   objects, each with a unique identity and local state.
>  (Is there an OO term for this?)
>  If this is the case, the old rope object must tell each person...
>    "...here, this is the new name of your rope object..." and then
>  the rope object must destroy itself.  Then the person object cannot
>  hard code a declartion to a rope object but keep an association or
>   delegation list somewhere.
>
>             So,      | rope |   mutates, then disappears
>                        /  \
>                    rope2a  rope2b

Actually when you look at the rope, it consists in this case
of three objects, two end objects and something that connects those.

	p1 <-> end1 <-> middle <-> end2 <-> p2

If middle breaks, can do the following

	p1 <-> end1 <-> middle1 <-> nil

		nil <-> middle2 <-> end2 <-> p2

So this would handle the break without having the problem
of mutating an object. Something which could be done
in the following "dirty" way in Smalltalk.

	middle := Middle new.
	p1 := Node connect: middle.
	p2 := Node connect: middle.
	" break now "
	middle := middle become: BrokenRope new.
Peter Kriens