At Tue, 1 Sep 2009 10:26:25 +0200, Bert Freudenberg wrote:
On 01.09.2009, at 04:07, tracker@squeakland.org wrote:
Scott Wallace updated SQ-288:
Attachment: lookLikeBug-sw.2.cs.gz
Version 2 uploaded: (a) Restricts the 'look like' tile to be available only in the viewers of Sketches; this makes it still compatible with the "powerful ideas" book, and with other support materials, while not tempting users to deploy it with non-sketch receivers. (b) 'look like' execution now consists of assigning a new graphic, rather than touching the buggy and dangerous morph-substitution code of old. This avoids the pernicious bug that is the subject of this ticket.
So that means a player cannot change its custome anymore, right? Isn't that a fundamental change in the Etoys philosophy?
If players and costumes are inseparable, why even talk about them separately? It would appear as if we now have different kinds of players, when before there was only one kind. How would we communicate the player-costume relationship then? Or do we just say that's an implementation detail?
Hmm, I wonder how "fundamental" this can be. From the Etoy user's POV, is it distinguishable (in a useful way) when the actual "costume" object is changed to some other object? Since there is no Etoys tile for getting the costume object and test its equality with some other object, etc. And, if you make your player wear a morph that was ticking, the result was the static graphic worn by the player. IOW, costume has never been a "first class" citizens. In that sense, we can still refer to the graphics change as costume change in the Etoys context, I think.
And, it was very easy to create an error when you change the costume to an instance of some other classes (as you know). This kind of errors in viewers, watchers, etc. can be uncaught from #step and easy to result in the loss of the whole work.
Yes, it surely limits what one *could* do. You used to be able to carefully construct a set of scripts that change the costume to other kind of object along with a flag of sort, and execute a script only when the costume is of particular type, for example. ... You could still do that; by writing a textual script.
However, the new code would not do the job that was done in #copyCostumeStateFrom: before.
------- self rotationCenter: aMorph rotationCenter. self rotationStyle: aMorph rotationStyle. self referencePosition: aMorph referencePosition. self forwardDirection: aMorph forwardDirection. -------
Even with this change, I'd expect to have them the effects...
-- Yoshiki