Big diatribe on protocols & classes (was Re: Can a Swarm instance be treated like a SwarmObject instance?

[Paul E. Johnson]

"William S. Shu" wrote:
>
> My questions then are the following:
> 1)    Can a Swarm instance be treated like a swarm object, if somehow, one
> manages to get it to adopt the Create and Drop protocols?  It seems the only
> difference (at interface level) between 'Swarm'  and 'SwarmObject' is the
> Create and Drop protocols that 'SwarmObject' adopts.

William's questions here are quite interesting and important to me. 
While trying to write notes about Swarm lately, I've been trying to
understand more deeply the issues of class and protocol.  One can get
pretty far with swarm using the templates from the swarmapps, but when
one tries to go "outside the box" then these fundamental issues start to
get important.

Perhaps now I could share a couple of these recent thoughts.  As usual,
I may be massively wrong, but only by declaring my ignorance am I able
to get people to correct me.  And, if I am wrong, I eagerly hope to
learn....

1. I think this protocol business is rather subtle!
A protocol is a list of methods in some header file. When you create a
class, and in your interface you add the protocol name at the end, as in
<aProtocol>, all you have done is promise that the implementation file
for your class will define all the methods of that aProtocol has or your
class will inherit those methods from elsewhere.  You don't "get" those
methods from a protocol, you are promising to implement them.  

This explains the kind of errors William mentioned, when the compiler
said methods XYX were not implemented by his class. If you put an
interface file with <Swarm> in it, then your class has to define all the
methods of the Swarm protocol, for example.  Those methods are listed in
the protocol definition in objectbase.h. The methods listed there for
the Swarm protocol must be present in the object you create that names
the <Swarm> protocol in its interface. If your class is created from
some other superclass, then, by definition (almost), your class will not
implement all the methods of <Swarm>.

You will note from studying the Swarm source that there are many many
examples in which a name is used to refer both to a protocol (declared
@protocol in a header file, as in objectbase.h) and a class (.h and .m
files, such as Swarm.h and Swarm.m).  A class must implement or inherit
all the methods listed in the protocol if it adopts the protocol. 
However, a class can have many more methods than are listed in the
protocol.  Hence, even though a class may not say it adopts the protocol
<Drop>, it may have methods like -drop. Confusing? Just wait.

2.  Just because the Swarm Docs say that Swarm does not adopt any
protocols, it DOES NOT MEAN that a Swarm does not inherit a lot of
methods.  This has been most frustrating to me and I think it is at the
heart of the problem William reported.  When Swarm does not adopt any
protocols, I think it only means that it is making no promises to
respond to any protocol's list of messages.  Swarm does in fact answer
to many of those methods, as I will now show.

How can you see what methods a Swarm object can respond to?  One can go
into the source and make a graph of the inheritance for Swarm.  Start at
Swarm.h and work your way backwards.  That's complicated, but I've done
it on occasion.  There's an easier way.  I've been proposing for a long
time that people use some tool like the OO-browser, that was distributed
with Xemacs 20.3.  I've grabbed that lisp package and installed it under
Xemacs 20.4, runs fine.  When I run OO-browser on heatbugs, for example,
I can take a class like Swarm and then get a listing of its "inheritance
tree" in the form of all the methods it gets from its ancestors. This is
output from the "features" command in OO-browser: (start at the low
level, work your way up)
Swarm
  - activateIn:
  - buildActions
  - buildObjects
  - getCompleteProbeMap
  - getProbeForVariable:
  - getProbeMap
  CSwarmProcess
    @ <SwarmProcess>
    - _performPlan_
    - activate
    - activate:
    - activateIn:
    - at::activate:
    - at:activate:
    + createBegin:
    - createEnd
    - getActivity
    - getInternalTimeMultiplier
    - getInternalZone
    - getSwarmActivity
    - getSynchronizationType
    - mapAllocations:
    - setInternalTimeMultiplier:
    - setInternalZoneType:
    - setPageSize:
    - setSynchronizationType:
    CreateDrop_s
      + create:
      + createBegin:
      - createEnd
      Customize_s
        - _setCreateByCopy_
        - _setCreateByMessage_:to:
        - _setCreateByMessage_:toCopy:
        - _setCreateBy_:message:to:
        - _setRecustomize_:
        + customizeBegin:
        + customizeBeginEnd:
        - customizeCopy:
        - customizeEnd
        + setTypeImplemented:
        Object_s
          @ <DefinedClass>
          @ <DefinedClass>
          @ <Serialization>
          @ <Serialization>
          - _lispOut_:deep:
          - addRef:withArgument:
          + alloc
          - compare:
          + conformsTo:
          - copy
          - describe:
          - describeID:
          - doesNotRecognize:
          - drop
          - dropAllocations:
          - free
          - getClass
          + getClass
          + getDefiningClass
          - getDisplayName
          - getIdName
          + getMethodFor:
          + getName
          + getNextPhase
          - getObjectName
          + getOwner
          + getSuperclass
          - getType
          + getTypeImplemented
          - getTypeName
          - getZone
          - hdf5In:
          - hdf5InCreate:
          - hdf5OutDeep:
          - hdf5OutShallow:
          + isSubclass:
          - lispIn:
          - lispInCreate:
          - lispOutDeep:
          - lispOutShallow:
          - perform:
          - perform:with:
          - perform:with:with:
          - perform:with:with:with:
          - removeRef:
          - respondsTo:
          + respondsTo:
          + self
          - setDisplayName:
          + setTypeImplemented:
          - shallowCopy
          - updateArchiver:
          - xfprint
          - xfprintid
          - xprint
          - xprintid
          Object


If you look through here, you see that an object of type Swarm does
indeed respond to messages like "drop".  It does not seem so from the
Swarm Docs because Swarm is not volunteering itself by adopting a
protocol, but clearly Swarm objects can do those things.

Now, consider the class SwarmObject.  It appears from the output below
that a SwarmObject can respond to fewer methods than a Swarm.  A
SwarmObject has a common inheritance with a Swarm all the way from the
Obj-C Object class to CreateDrop_s.  Then the two appear to branch
apart.

SwarmObject
  - eventOccurredOn:via:withProbeType:on:ofType:withData:
  - getCompleteProbeMap
  - getIdName
  - getInstanceName
  - getProbeForMessage:
  - getProbeForVariable:
  - getProbeMap
  CreateDrop
    - createEnd
    CreateDrop_s
      + create:
      + createBegin:
      - createEnd
      Customize_s
        - _setCreateByCopy_
        - _setCreateByMessage_:to:
        - _setCreateByMessage_:toCopy:
        - _setCreateBy_:message:to:
        - _setRecustomize_:
        + customizeBegin:
        + customizeBeginEnd:
        - customizeCopy:
        - customizeEnd
        + setTypeImplemented:
        Object_s
          @ <DefinedClass>
          @ <DefinedClass>
          @ <Serialization>
          @ <Serialization>
          - _lispOut_:deep:
          - addRef:withArgument:
          + alloc
          - compare:
          + conformsTo:
          - copy
          - describe:
          - describeID:
          - doesNotRecognize:
          - drop
          - dropAllocations:
          - free
          - getClass
          + getClass
          + getDefiningClass
          - getDisplayName
          - getIdName
          + getMethodFor:
          + getName
          + getNextPhase
          - getObjectName
          + getOwner
          + getSuperclass
          - getType
          + getTypeImplemented
          - getTypeName
          - getZone
          - hdf5In:
          - hdf5InCreate:
          - hdf5OutDeep:
          - hdf5OutShallow:
          + isSubclass:
          - lispIn:
          - lispInCreate:
          - lispOutDeep:
          - lispOutShallow:
          - perform:
          - perform:with:
          - perform:with:with:
          - perform:with:with:with:
          - removeRef:
          - respondsTo:
          + respondsTo:
          + self
          - setDisplayName:
          + setTypeImplemented:
          - shallowCopy
          - updateArchiver:
          - xfprint
          - xfprintid
          - xprint
          - xprintid
          Object

So, I think to understand the problem, one ought to remember that the
list of methods in the protocol listing is not an exclusive list of
methods that an object can carry out.

-- 
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.