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. openInHand (pick) takes a morph 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.

HTH .. Subbu

Robert

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

On 9/28/10, Robert Hawley rhawley@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