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