Why should this not work?

Alan Kay alan.kay at squeakland.org
Tue Feb 27 16:05:13 UTC 2007


Hi Bob --

You could (and maybe should) consider just making an architecture in 
Squeak that serves your purposes. The Player architecture in Etoys 
was an attempt to make a much simpler (but still comprehensive) 
object model, and a viewing architecture that lies "between" (if that 
is a reasonable term) Morphic and MVC. One needs to do make simple 
ticking scripts like:

      foo forward 20
      foo turn 10
      Holder's cursor increase by 1
      foo look like Holder's player at cursor

And there are also many needs for multiple views. One of the things 
that occurred to us many years ago, and was intensified when 
Hypercard came out, is that if you only had "cards": as one's graphic 
type, could embed them in each other as much as needed, they could be 
any shape (a generalized curve with holes), etc., then you would have 
a very capable but extremely simple way to think about manifesting 
visible properties. This came from the observation that a Hypercard 
card could easily be made to be a view of any set of cards. Morphic 
does some of this but it really incorporates the Model and the View 
in one object. There needs to be a way to have more than one view, 
and this where the costume idea came from.

You might like to look at Andreas' Tweak architecture, which is most 
easily seen (and is kept up to date) in Croquet (opencroquet.org). 
This (in my opinion) is a much better and more useful graphics 
architecture than Morphic (and it had the advantage of learning from 
quite a bit of Morphic experience). The Tweak graphics architecture 
is kind of a grown up version of Etoys.

Cheers,

Alan




At 07:35 AM 2/27/2007, Robert Hawley wrote:
>Hi Andreas
>
>I agree that standardly defined things like forward: could be relayed
>from the morph to the player using messages that do the assuredPlayer
>job. I don't know if there is any fundamental reason why this should not
>be included in the released image? (I wonder if the design decisions
>include factors to do with efficiency for example?). This relaying does
>provide trackable messages and it answers part of the issue I am
>questioning.
>
>However, this won't work for user provided scripts, as they are specific
>to an individual player. These associate with a specific named class
>(e.g., Player57) and so it would not be possible to automatically plant
>relaying calls in the (more generic) morph class. My 'fix' (hack) deals
>with this case too. I don't (yet) understand the issue of subclasses of
>Player you mention (the scripts are already in a named subclass of
>player and they are being picked up ok) - I will look into it.
>
>Yours
>
>Bob
>
>-----Original Message-----
>From: Andreas Raab [mailto:andreas.raab at gmx.de]
>Sent: 27 February 2007 07:44
>To: The general-purpose Squeak developers list
>Subject: Re: Why should this not work?
>
>Robert Hawley wrote:
> > Hi Andreas
> >
> > If you argue that morphs are designed only for eToy scripting then I
>suppose I have no point to make.
> >
> > However, morphs are also used for other things.  In fact many serious
>Squeak programmers profess 'chosen ignorance' of eToys and yet use
>morphs all the time - to the extent that several want to throw away the
>eToys so that they can use morphs the way that they want to and clean
>the system up.
> >
> > The transition from eToys scripting to programming with Smalltalk is
>clumsy when trying to use it for teaching.  When scripts become
>limiting, the shift to using proper browsers is not very straight
>forward (or well documented).  I would like to be able to go more
>naturally through this transition - and without having to assume
>expertise at the guru level.  Given that scripts can do forward: then it
>is observably odd not to be able to the same thing when coding Smalltalk
>(hence my simple initial question).
>
>None of the above really changes what I said (and which I think you
>misunderstood). I didn't claim that morphs were only designed for eToys
>scripting but this particular aspect (logo-like behavior) was. Because
>of that you can only really use it via its player and you should expect
>to find a certain amount of idiosyncrasies (like #assuredPlayer) when
>you deal with it. If you wanted to change that it would amount to a
>serious bit of redesign.
>
> > doesNotUnderstand: aMessage
> >       "RHawley 9/18/2006 06:23"
> >       " Redirects the message to the Morph's player if it can respond.
> >               Allows commands like forward: to be sent to the morph
>directly
> >               (prevously they would have to be directed to the morph's
>player explicitly.
> >               Now use, X forward: 10    instead of    X assuredPlayer
>forward: 10).
> >               This is useful for actions associated with the 'Press
>Me' button"
> >       self hasExtension ifFalse: [
> >               (Player lookupSelector: aMessage selector) ifNil: [
> >                       ^super doesNotUnderstand: aMessage]].
> >       (self assuredPlayer respondsTo: aMessage selector) ifTrue: [
> >               ^self assuredPlayer perform: aMessage selector
>withArguments: aMessage arguments].
> >       ^super doesNotUnderstand: aMessage
> >
> > With this code, it becomes possible to use standard browsers to write
>code in a way that is more naturally consistent with the scripts the
>students have already met.
>
>That version is a definitive improvement (though it still suffers the
>issues about Player subclasses) but generally I just don't think we
>should "introduce MI" in a singular place in the system. I'd rather add
>a method like:
>
>Morph>>forward: amount
>         ^self assuredPlayer forward: amount
>
>which seems much more straightforward for the things you're trying to
>do.
>
>Cheers,
>    - Andreas




More information about the Squeak-dev mailing list