So I swear that I used to be able to send #storeString to morphs. Maybe I dreamed it. 

Around the time we shipped the 4.0 artifact, I noticed that upon sending #storeString to a visible morph, the CPU would spike and the image would hang.

I believe I have figured out why that happens: I think that #storeString is recursing on the Morphs 'owner' ivar, thus attempting to store the world, which probably has references to much of the rest of the system.

One might argue that this is expected behavior, but it isn't very useful expected behavior AFAICT. I would really like to be able to construct a prototype manually through morph composition/decomposition, and get code to recreate the resulting object, so that the final product can be developed programmatically.

I tested my hypothesis by creating a new morph, opening it in the world, inspecting it, and assigning nil to it's owner ivar, and then sending storeString to it. This worked as I expected.

One way to make it work would be to implement storeString on Morph: send #veryDeepCopy to self, nil the owner reference on the copy if the owner (is the? is a?) world, and then send a message (say, #superStoreString) to the copy that does super storeString, returning it's answer. This prevents the morph in the UI from losing it's reference to the world, and gives you back what you were probably expecting (something useful.)

OTOH, maybe that's a terrible, ugly hack. Maybe it makes sense to fix the problem somewhere else. Maybe there are nasty gotchas involved. Maybe I'm the only person in the world who wants to interact with Morphic in this way.

What do the good people of Squeak think?