(do we have RFC's in squeak?)

When a morph is dropped into a world and if it has a step method the 
world starts stepping the morph (calling the morphs step method). This 
is true even if prior to the drop the morph wasn't stepping and even if 
a stopStepping message had been sent.

(see Morph>>justDroppedInto:event:)

Besides being a poor design choice it seems redundant. If a morph is 
stepping when it is picked up it continues to step, picking up the morph 
doesn't stop it from stepping.

It's a poor design choice because if, for example,  I have a morph that 
moves from its starting position to some other position via step, then 
stops due to some event, that sequence shouldn't be triggered by the 
user rearranging her desktop. And while it's possible to work around 
this by overriding Morph>>whatsSteps it just that, a work around.

If the state of the morph's stepping needs to be know when it is dropped 
worldState keeps a list of stepping morphs. But again I don't see why 
this is needed because the morph's stepping state isn't changed by being 
picked up.

Comments?

-- 
Frank Caggiano				"The best education for the best
caggiano at crystal-objects.com		is the best education for all."
http://www.crystal-objects.com/		   Robert M. Hutchins

Logo Users Ring
http://www.crystal-objects.com/logo/logoring.html