Re: simple objc/swarm question

[Unknown]

> I was thinking just as I could subclass off SwarmObject, say, 
> I could subclass off of List, adding variables and methods
> as I need to my subclass of List.  (eg I might want a method
> to return the n-th item in the list, not just fisrt and last.)
> 
> What fundemental idea am I missing here?
> Is there a way to do what I want?

The header files for defobj, collections, and activity only publish the
name of "type" objects which know how to create instances having their
specified interfaces.  These objects, when they receive create messages,
pick some internal class to instantiate based on create-time options
("set" messages) they might have received between createBegin and
createEnd.  In the case of List, the actual class they instantiate is
currently either List_linked (a conventional doubly linked list) or
List_mlinks (links imbedded in members, used as an optimization by the
activity library).

As discussed in an OOPSLA '95 position paper (available on the Swarm home
page) this technique gives a great deal of flexibility to vary the
implementation based on particular requirements, but does undoubtedly make
subclassing more difficult.  Further use of these techniques is expected
for the near future; lists, for example, will have a third implementation
based on blocks of contiguous members.

In all cases, the library will have to document subclassing requirements
for each class intended to be subclassed.  Subclassing documentation,
including extra details like what can be safely overridden vs. must be left
intact, is always more complex than simple usage documentation, but these
techiques raise the difficulty up a notch.  However, many of the basic
classes they're used for, such as many of the activity library objects,
are not intended to be subclassed except in very specific ways.

In this case, you should able to inherit from List_linked (one of the hidden
classes), merely allocate it (using [aZone allocIVars: [List_linked self]])
and have a valid list, but other subclassing cases may be more difficult. To
inherit from List_linked, you'll also have to #import <activity/List_linked.h>.
I'll give this a try to make sure it works, but I think it's all you'll need
to do what you want.

Another way to reuse a class in another class is just to include an
instance of it in an instance variable and pass through the specific
messages you to have available on the new class.  Obviously this is more
cumbersome and less efficient than simply subclassing, but it does give
more control over what can happen under the new interface.  What we're
likely to do is document the easy ways to subclass the particular
implementations we expect to be subclassed, and explain that others should
just be reused as instance variable components.

Sorry about the lack of documentation on something so basic.  We've still
been debating the final form of the activity (scheduling) library and
that's likely to show up in our upcoming release (coming up soon) before
getting the rest of the collections library in final shape.  As the
current documentation indicates, what's there now is pretty much just what
had to be there to get all the scheduling apparatus in place.

Roger


----- End Included Message -----