[squeak-dev] A case for #storeString on Morph

Bert Freudenberg bert at freudenbergs.de
Wed Sep 15 23:50:50 UTC 2010


On 15.09.2010, at 04:41, Casey Ransberger wrote:

> 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.

It is.

> Maybe it makes sense to fix the problem somewhere else.

Maybe.

> Maybe there are nasty gotchas involved. Maybe I'm the only person in the world who wants to interact with Morphic in this way.

You might, actually ;)

> What do the good people of Squeak think?     

I think "terrible, ugly hack" describes it pretty well ;)

But since nobody else is using this, why not fix it to do what you want? I'd do it differently though - override storeOn: to actually produce a sensible result. Not meddling with copying, but by writing out code that would properly re-generate that morph. That way it could even look nice, as if you had hand-written the code.

- Bert -




More information about the Squeak-dev mailing list