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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

rhawley
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)
Reply | Threaded
Open this post in threaded view
|

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

K K Subbu
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

Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
In reply to this post by rhawley
Robert

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

On 9/28/10, Robert Hawley <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
In reply to this post by K K Subbu
On 9/28/10, K. K. Subramaniam <[hidden email]> wrote:

> 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.

I assume so as well.

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.


Yes, that might have been a good idea 10 years ago. But these days it
does not matter at all in terms of speed having these methods.

forward: and turn:

which delegate to the player.

--Hannes