[squeak-dev] forward: and turn: in Morph - are we missing immediacy?

Robert Hawley rhawley at plymouth.ac.uk
Tue Sep 28 00:48:37 UTC 2010


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)


More information about the Squeak-dev mailing list