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

Hannes Hirzel hannes.hirzel at gmail.com
Tue Sep 28 09:15:46 UTC 2010


Robert

My short answer is
YES, we are missing immediacy.
The longer answer is below....

On 9/28/10, Robert Hawley <rhawley at plymouth.ac.uk> 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.
>
> 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)
>


I like your analysis.

Given the fact that class Morph has 1000 methods and quite a lot of
turtle related things I agree with you that these two methods should
be there.
(I just posted on the Pharo list yesterday a class hierarchy graph
done with Mondrian which shows the relative complexitiy of the
different subclasses of Morph; it should have appeared here as well
but the image was too large for the list)

I see that for you as a University teacher this is a necessity to have
these methods. The time with students is limited and they need the
obvious (principle of least surprise). They need success in the first
few hours. And doing turtle graphics is something which gives
immediate success.


> x := EllipseMorph new openInHand.
> x forward: 100.

Is obvious.

> You have to do the following once to create the 'player':
>
> x := EllipseMorph new openInHand.
> x assuredPlayer forward: 100.

Is not obvious.

So these proxy methods are a real need.


How to proceed?
Write down your proposal as working code and commit it to the inbox of
the trunk.


1) Take a new copy of a trunk image (e.g. the latest one from
http://ftp.squeak.org/trunk)


2) Choose update source by executing
        MCMcmUpdater defaultUpdateURL: 'http://source.squeak.org/trunk'.

3) Mouse-menu --> Update Squeak

4) Add the two methods you want included

5) Open a Monticello Browser - you will find that the package in which
you have added the two methods has a star.
5a) select that package
5b) click on http://source.squeak.org/inbox
5c) Click on 'Save'
5d) Add a comment - the comment will appear on this mailing list

6) A commiter will pick it and comment on it and if he agrees it will
be commited to the trunk. Tobias had a proposal yesterday about spaces
in selectors and it was in the trunk within 1 hour as Levente picked
it.

HTH

Hannes



More information about the Squeak-dev mailing list