forward: and turn: in Morph - are we missing immediacy?

> I find it odd, and obscure that forward: and turn: are not in the class
> Morph.
>
> This means that the following gives an error:
>
> x := EllipseMorph new openInHand.
> x forward: 100.
>
> You have to do the following once to create the 'player':
>
> x := EllipseMorph new openInHand.
> x assuredPlayer forward: 100.
>
> Is there any reason why forward: and turn: should not be in Morph?
>
> They are just the methods:
>
> forward: distance
> self assuredPlayer forward: distance
>
> turn: angle
> self assuredPlayer turn: angle
>
> Similar pen driving methods already exist in the Morph pen category such as
> liftPen, lowerPen, choosePenColor: .
>
> I guess there is an argument that using forward: and turn: in 'ordinary'
> programming is inefficient because of the overhead of the morph extension
> and player.  Hiding forward: and turn: discourages their use in this
> context.
>
> HOWEVER  One of the criticisms of Squeak is that there is a divorce between
> Squeak proper and Morphic/Etoys.  In my view this divorce starts with the
> omission of the forward: and turn: methods from Morph.  Why not be able to
> make simple use of these elemental messages? Having the current peculiar
> state change depending on the existence or otherwise of the player is ugly
> programming at best and bad computer science principle at worst.
>
> My concern is with initial teaching of Smalltalk and NOT with Guru
> programming.  Guru programming treats Smalltalk as a place to do complex
> system programming, whereas I think that it does not go back to the first
> principle of Smalltalk in that it should be friendly for CHILDREN.  Now
> Etoys, however nice it is, is not Smalltalk.  I would like to be able to use
> morphs in Squeak Smalltalk in a more immediate fashion, and I think that
> introducing these two methods to the Morph class is a necessary first step.
>
> Driving morphs is a very visible and obvious first example to use in
> teaching.  Morphs have a relationship with Smalltalk objects (instvars +
> behaviours) but are far more dynamic and interesting.  Why have we been
> denying that very dynamism by omitting these two methods from Squeak?
>
> Or put it the other way: can we add these two methods to Squeak please?
>
> Yours
>
> Bob
> (Robert Hawley)
>

> On Tuesday 28 Sep 2010 6:18:37 am Robert Hawley wrote:
>> I find it odd, and obscure that forward: and turn: are not in the class
>> Morph.
>>
>> This means that the following gives an error:
>>
>> x := EllipseMorph new openInHand.
>> x forward: 100.
> I suppose you really meant openInWorld which creates a container-contained
> relationship between a morph and its world.

> out of its container and so geometric ops no longer apply.
>
> Conceptually, Morphs exist as pure shapes composed hierarchically and react
> to
> Events from Hands. Dropping them into a world establishes a transform for
> its
> owner for rendering it in its visual fields. Transform parameters are
> affected
> by ops like move, rotate, scale, align, distribute, lower, raise etc. These
> messages are sent to the owner. Self-centric ops like forward: and turn:
> operators require an agent like Player to mediate between morph and its
> owner.
>
> I suspect space and performance considerations prevented such transforms
> from
> being put into every Morph.