object creation

[Roger M. Burkhart]

Christoph,

Glad to hear of your successful model with Swarm!  In response to your
question:

> Besides: How was the idea of Object creation implemented in swarm. We couldn't
> see behind it. If we want to create a Schedule, we must send a message to an
> Object called 'Schedule'. But there is no class Schedule.

The object you send the message to (e.g. Schedule) is an special factory
object that selects a class to implement the created object based on
optional "set" messages between createBegin: and createEnd messages.  The
Swarm kernel libraries defobjc, collections, and activity libraries
separate the definition of object "type", defined strictly by interface
definitions coded as Objective C protocols, vs. classes which implement
these interfaces in various possible ways, and which are hidden entirely
from the interface caller.  There may be multiple classes which implement
the same type to optimize or satisfy requested options, and the originally
allocated object can change its class to reflect the implementation
finally selected.  Classes in other libraries implement the same style of
create protocol, but assume only one implementing class and a less-strict
separation of the creation phase.

For more background, at least on motivation, I'd suggest the OOPSLA '95
position paper ("Create-phase Protocols for Object Customization") on the
Swarm home page.  On details of implementation, there's special machinery
that records the way to create a type for any requested customization.
During initialization, the object you send the message to (Schedule) is
set to one of these "CreateBy" factory objects initalized with default
options.  Some of this machinery is in process of being restructured and
simplified so other libraries can use it also.  In the meantime, it's
a hidden complication that helps support the variation that can occur in
collection and activity structures.

Roger Burkhart