[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
|