[etoys-dev] Players and costumes

[Yoshiki Ohshima]

At Tue, 1 Sep 2009 10:26:25 +0200,
Bert Freudenberg wrote:
> 
> On 01.09.2009, at 04:07, tracker at 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