Why should this not work?

Robert Hawley rhawley at plymouth.ac.uk
Tue Feb 27 02:22:15 UTC 2007


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).
 
Sorry - I grabbed the wrong version of my 'fix' for the previous post. The following is the best I've got so far (and it does have a comment). (Is it less horrible, and does the comment make it any more acceptable?(!)). I am not advocating multiple inheritance - this is something of a tongue-in-cheek solution. It will always be a dilemma as to how to make a composite object look as if it is a single object - arranging for some form of relay is always going to be necessary. Either the programmer will have to know how to address the internal objects (not always easy to learn however because of all the tracking this entails), or instead a set of messages have to be provided.  The doesNotUnderstand: hack may not be desirable, but there is no law against it, it is good fun, and it does do the job! In trying to provide a consistency it is (afterall) having to bypass behaviours that are a bit side-effectual and modal.   It also allows the illusion of the simple message sending OOP paradigm to be maintained for morphs for a bit longer without actually interfering with the underlying player/costume design.

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.

Yours

Bob




> ... that's the fix, but my question is "why not?".  Why should morphs not be able to move forward without having to fiddle with the player?  ... why should this not be a morph functionality?  ...  why should assuredPlayer be a coding inconvenience when it is not so for scripts?  It seems very odd and idocyncratic - particularly when morphs are also such a fundamental of computation independantly of eToys.  

It's not a "fix" it's documenting a design decision. It is intentional 
that scripts act on players so that their costumes (morphs) can be 
changed at will. Why that is the case requires a bit more history and 
explanation of the player architecture than I feel like giving right now 
(but from an architectural point of view it was a very wise decision).



>From the point of view of teaching initial programming (as opposed to using scripts) in Smalltalk, this is an arbitary separation - clumsy and artifactual - for example, liftPen and lowerPen assure the player for themselves, so why not for forward: ?.  Also, if I implement a script it associates with a player, but if I want to call it using the code as code why should the morph not know to check whether the player implements it?  There are probably good reasons for the way morphs and players have been implemented - I am not clear whether these are stylistic, driven by efficiency issues, or what.

They are driven by the need for flexibility (as mentioned above, one 
goal is to be able to change costumes) and robustness. And while you may 
find this "clumsy and artificial" please keep in mind that the goal for 
these methods was scripting not whatever it is you are doing.

> I have a fix that makes this issues transparent - effectively it gives multiple inheritance from either morph or player.  Are there reasons why this is not a good idea? 

Yes. I'm not even sure where to start. But since you seem to come from 
education, one of the reasons why this is a horrible idea is that you 
are introducing multiple inheritance in a system that assumes single 
inheritance without even documenting it. People using Squeak are used to 
(and being taught) to look at the inheritance chain to find whether a 
class/object implements a message. You are just breaking this assumption 
big-time and without giving anyone a clue that you are doing so. That 
message, doesn't even have a comment! Besides the code is broken too, 
since it doesn't check for player subclasses, will not handle DNUs 
correctly in all cases etc. etc. etc.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list