pcb@cacs.usl.edu (Peter C. Bahrs) (10/29/90)
> I wrote... Responses... Well I have seen a lot of interesting responses on the net and through email. I wish news allowed graphical postings so I could send a picture of the solutions. 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 Any comments? I suspect that all of this can be modeled in the behaviors of the objects in languages like C++ and Smalltalk. But are there systems that provide mutation? /*----------- Thanks in advance... --------------------------------------+ | Peter C. Bahrs | | The USL-NASA Project | | Center For Advanced Computer Studies INET: pcb@swamp.cacs.usl.edu | | 2 Rex Street | | University of Southwestern Louisiana ...!uunet!dalsqnt!gator!pcb | | Lafayette, LA 70504 | +-----------------------------------------------------------------------*/
ellson@cbnewsk.att.com (john.ellson) (10/29/90)
From article <17486@rouge.usl.edu>, by pcb@cacs.usl.edu (Peter C. Bahrs): >> I wrote... Responses... > > Well I have seen a lot of interesting responses on the net and through > email. I wish news allowed graphical postings so I could send a > picture of the solutions. > > 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 > > Any comments? I suspect that all of this can be modeled in the > behaviors of the objects in languages like C++ and Smalltalk. But > are there systems that provide mutation? > > /*----------- Thanks in advance... --------------------------------------+ > | Peter C. Bahrs | > | The USL-NASA Project | > | Center For Advanced Computer Studies INET: pcb@swamp.cacs.usl.edu | > | 2 Rex Street | > | University of Southwestern Louisiana ...!uunet!dalsqnt!gator!pcb | > | Lafayette, LA 70504 | > +-----------------------------------------------------------------------*/ Perhaps, because you know that the rope is breakable, you should model rope-end as the objects instead of rope. Then each person has a relationship with (is holding) a different rope-end instance where those rope-ends in turn have a connected relationship with each other. Then, when the rope breaks, only the connected relationship is changed. The person-holding-rope-end structures are unmodified. The behavior of the connection relationship would be to immediately instantiate two new rope-ends. You could also model splicing by deleting two rope-end instances and connecting the remaing rope-ends directly. John Ellson (j.ellson@att.com)
pkr@media01.UUCP (Peter Kriens) (10/30/90)
> 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
edwardj@microsoft.UUCP (Edward JUNG) (10/31/90)
and solve them using a monolithic program written in Fortran and running on a Cray YMP. Hopefully by the time the Object-Oriented Design phase is over, I will have solved this problem three times using the old tools approach. ;-) -- Edward Jung Microsoft Corp. My opinions do not reflect any policy of my employer.