Hi, Hannes,

"Uniclass" got its name because in the beginning it meant a class 
that always had exactly one instance.

For years now, uniclasses have been capable of having multiple 
instances, so the name is nowadays misleading.  Still, it has stuck 
and is much used in comments and in method names.

A uniclass is an anonymous class created on behalf of the user to 
reflect user-defined state and behavior.  If you create a script with 
tiles, the script is a method and the method needs a class and so a 
uniclass is created for it.  If you add an instance variable to a 
user-scripted object, the instance variable needs a class so again we 
turn to a uniclass for it.

The same uniclass mechanism is used for Stacks, where the instance 
variables are automatically created on behalf of the user as the user 
places background fields into the stack (whereas in etoys, uniclass 
instance variables are manually specified,) and the methods are 
typically associated with background buttons.

In the case of a Stack, only one single instance of a uniclass is 
seen at any given moment (i.e. the "current card"); in the case of an 
etoy, multiple instances may be visible concurrently.

As currently used in Squeak, Uniclasses are subclasses of Player or 
CardPlayer.  In either case, the uniclasses and their instances serve 
to:

*  Provide a seat of *identity* that is impervious to the 
interposition of TransformationMorphs, and to the change of costume. 
As such, they provide the basis for the "reference" scheme by which 
users' scripts refer literally to visible objects, as well as the 
foundation for a variant-view scheme.

*  Provide a way for user-defined scripts (methods) and 
user-specified data (instance variables) to be defined and 
maintained, by direct manipulation, without the user explicitly 
needing to create or modify classes by textual class-structure 
expressions such as are required for class-definition in a Browser.

*  Provide a common "fat" baseline of capability for user-defined 
objects, because they descend from a strongly-capable progenitor 
class.


More needs to be written to clarify what this stuff is all about, and 
why, and where it is headed, but in the meantime, I hope this helps a 
little.

   -- Scott

At 10:15 AM +0100 2/16/02, Hannes Hirzel wrote:
>Hi
>
>a little question
>
>Class Player is a Model.
>
>The class comment says
>'Scripts are defined in subclasses of Player.  These
>are UniClasses'.
>
>I don't understand what 'UniClass' means here. I was considering it
>meant 'Singleton'. But in the case of importing a tab delimited
>text file into a StackMorph (_very_ nice) I found out that the
>Player class generated was actually a data container with getters
>and setters named after the background fields.
>
>Question: What does Uniclass mean here? And more generally
>some more information about the Player subhierarchy would be
>appreciated.
>
>Thanks
>
>Hannes Hirzel