Re: subclassing the Set object type

[rmb]

Wojtek Kopczuk wrote in response to Bohdan Durnota:

> address@hidden (Bohdan Durnota) wrote:
> > 
> > A "simple" question:
> > 
> >         How can one (easily) subclass the Set object class? 
> > Ideally, I would have thought that
> >         #import <collections.h>
> > 
> >         @interface MySet : Set {
> >         ... }
> >         ...
> >         @end
> > 
> > would have been sufficient, but this does not work.
> 
> You cannot. But you can define another class which contains
> a Set object as an attribute and forward all of the messages
> to this attribute:
>
> @interface MySet : SwarmObject 
> { id set; ... }
> -forward: (SEL) aSelector : (arglist_t) arguments;
> ...
> @end
> 
> @implementation MySet
> -forward: (SEL) aSelector : (arglist_t) arguments {
>   return [ set performv: aSelector : arguments]; }
> ...
> @end

We ought to make this an entry in our frequently asked questions.  We do
expect to improve the subclassing situation somewhat in upcoming releases.
In the meantime, there are a couple sections of the Swarm reference
documentation that briefly explain the situation.  The first, from the defobj
ref docs at
http://www.santafe.edu/projects/swarm/swarmdocs/src/defobj/subclass.html:

  Subclassing from classes that implement object types (see module definition
  conventions for a summary of the differences between types and classes) is
  still complex. In general, classes that implement a library are not
  automatically available for user as superclasses. A library must document
  specifically which superclasses are published for user classes to inherit
  from, along with specific rules that user subclasses must follow when
  implementing new behavior.

The second, from the collections ref docs at
www.santafe.edu/projects/swarm/swarmdocs/src/collections/subclass.html:

  Until the collections library has been fully implemented, subclassing
  conventions from collections implementation classes are still in flux. In
  general, these classes will be among the most complex uses of multiple
  classes selected to implement an independent object type. (See module
  definition conventions for a summary of the distinction between types and
  classes.) New methods are being developed to simplify subclassing from such
  implementations. In the meantime, if you need to use to a collection within
  the implementation of your own class, just put an instance variable in your
  class and put the collection in that, and pass through the messages of the
  collection you want to have available on your class to this variable. In many
  if not most cases, this is better design anyway, because you control all use
  of the underlying structure.

There have been a couple of threads on the mailing list that dealt with the
subclassing issue from collections.  These archives are now not only available
in web form, but searchable (accessible from
http://www.santafe.edu/projects/swarm/mailing-lists.html).

Two particular threads found by a search of "subclass" include:

http://www.santafe.edu/projects/swarm/archive/list-archive.9511/0011.html
(Re: simple objc/swarm question)

and:

http://www.santafe.edu/projects/swarm/archive/list-archive.9606/0031.html
(subclassing/collections)

The first is a basic summary of the situation on subclassing from collections,
and make the same recommendation to include the set in your instance variables
that Wojtek made.  The second started a thread in which Claudia Pahl
explained how she did eventually get subclassing from one of the List
implementations to work.

In the case of Set, the current implementation is so much of a placeholder
for entirely new implementations that will replace it (based on balanced
trees and other data structures) that I'd recommend not inheriting from the
one current implementation directly, but instead using pass-through of
messages to a set contained in a local instance variable.  This pass-through
may be done either with a generic forwarding technique, such as Wojtek
showed, or just by coding the specific messages of a set that you want to be
available.  (Often it's appropriate not to provide full manipulation of the
underlying class from the user of the subclass, depending on what service
you're trying to provide there.  But Wojtek's suggested forwarding is a
good way to provide all the functionality of the local set on your own class,
if that's what you want.)

Roger Burkhart