Robert Hawley wrote:
... 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