On Monday 14 Apr 2008 2:47:12 am Scott Wallace wrote:
When using siblings, what's really happening underneath is that there is a custom Player "Class" is created to bear the shared code, and the siblings are individual "Instances" of that class. "Class" and "Instance" are among the most fundamental concepts of object-oriented programming, but we don't much use the terms "class" and "instance" in the etoys UI, nor in any documentation I'm aware of.
The viewer category "an Object" contains a class tile. An EToy is initially in "UnscriptedPlayer" class. When the first script is created, the class gets reassigned to a unique Player<n> value. This value stays even if all the scripts in the Player are deleted. Should it revert to UnscriptedPlayer in this case?
(A notorious exception is the "all instances" checkbox in the all-scripts tool.) We refer to "siblings" but don't have a formal term for the "class". Hmm... maybe the checkbox should read "all siblings" rather than "all instances"...
and also in the "make a sibling instance ..." in the siblings menu item of red halo button.
The copy tile in miscellaneous category uses the term "clone" for sibling.
This mixing of metaphors (drama, family, genetics) is confuses children. So, I use the analogy of chorus dancers to explain this part of EToys. Each dancer in the group may wear a different costume, have different heights or locations on stage, but they all perform to the same script. One eight-year applied the concept to animate falling snow for a winter scene.
Subbu