[Q] StackMorph and Uniclass

Hannes Hirzel hirzel at spw.unizh.ch
Sat Feb 23 11:05:44 UTC 2002


On Sat, 16 Feb 2002, Scott Wallace wrote:

> 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


Yes, thank you. The information you gave clarified questions I had
about the StackMorph class and I now feel confident to use it.

Regards
Hannes Hirzel




More information about the Squeak-dev mailing list