Hi Kemal,
it's part of the Etoys philosophy to have only a single class of player.
For example, you can change the costume (the morph) of a player dynamically, so the player needs to have the vocabular to serve all the >different costumes it could wear. This would break if you create specialized subclasses of Player.
Btw, in Smalltalk adding extension methods to other classes is not
considered as "intrusive" as in other languages.
Hth,
- Bert -
I don't understand. What is the best option for making morphs scriptable? 1. Extend Player or 2. Create a subclass of Player and add the method #newPlayerInstance to the morph which returns the correct instance of Player (DiceMorph and CalculatorMorph do this)
What problems could cause the second option? Bye
Am 29.09.2008 um 12:33 schrieb Ricardo Moran:
Hi Kemal,
it's part of the Etoys philosophy to have only a single class of
player. For example, you can change the costume (the morph) of a player dynamically, so the player needs to have the vocabular to serve all the >different costumes it could wear. This would break if you create specialized subclasses of Player.
Btw, in Smalltalk adding extension methods to other classes is not
considered as "intrusive" as in other languages.
Hth,
- Bert -
I don't understand. What is the best option for making morphs scriptable?
- Extend Player
or 2. Create a subclass of Player and add the method #newPlayerInstance to the morph which returns the correct instance of Player (DiceMorph and CalculatorMorph do this)
What problems could cause the second option?
As I mentioned above, if a user changes the custom of a player from DiceMorph to CalculatorMorph then the method calls will break.
I have no idea who created Dice and Calc but these are bad good examples if they subclass Player.
- Bert -
squeak-dev@lists.squeakfoundation.org