[Q][BUG] Why rotated morph change class ?

Marcin Tustin mt500 at zepler.net
Thu Sep 2 10:09:24 UTC 2004


On Thu, Sep 02, 2004 at 06:59:36AM -0300, Lic. Edgar J. De Cleene wrote:
> I doing Squeak teaching to student's of my class.
> 
> They are about 20 years old and see something OOP and Smalltalk before using
> Smalltalk Express as part of his curricula.
> 
> When I show Squeak to them in lab , I took a EllipseMorph from flaps,
> duplicate several times , changing color via halo and to one of ellipses I
> do rotate via halo too.
> 
> I open a Workspace and type:
> 
> World submorphs do: [ :m| (m isKindOf: EllipseMorph ) ifTrue: [ m delete ].
> 
> Guess what:
> 
> The rotate one don't delete. I know what should be originate a
> TransformationMorph , so I pick again via halo and raise a inspector.
> 
> Surprise!! The inspectors says what still is a EllipseMorph.
> 
> Then I subclass Trash can and intercept dropping whit a self halt.
> 
> Now I see what morph dropped was TransformationMorph.
> 
> They says to me what this is "lack of consistency" and " a real object don't
> should change class by the fact you rotate it"
> 
> And how I don't have clever answers ,here I asking to list what to say.

    While I do think it passing strange that rotation causes a class-change
(which I didn't realise was possible in Smalltalk), class-changing can be
extremely useful. For instance, it allows one to add new methods to an object
by creating a new class derived from the old class, then changing the class
of the object. Of course, naive use has problems, and smalltalk may have
better ways of doing that, but that is an example of a real use



More information about the Squeak-dev mailing list