Re: Swarm Design Philosophy

[Marcus G. Daniels]

>>>>> "PJ" == Paul Johnson <address@hidden> writes:

PJ> I see no new functionality in Swarm by converting the
PJ> classes to protocols, I just see a lot of broken code. 

Here are some reasons:

1.  Consistency

    The core libraries (defobj, collections, activity), are done this way.
    Objectbase and simtools are done this way and, with Swarm 1.1,
    the interface to simtoolsgui is provided by protocols.
    For the AWT interface, we needed an abstract interface to GUI features,
    so the tkobjc functionality is now hidden behind a protocol.

2.  Flexibility

    Applications that use only protocols to talk to Swarm have no
    knowledge of the internal structure of Swarm classes.  This is useful
    for a variety of reasons:

    A.  It makes it easier to run models `over the wire', e.g.
        coarse parallelism using Swarm `servers'.

    B.  It gives us more flexibility to change things behind the scenes
        without causing disruption to users.

    C.  Precise and minimal interfaces to Swarm things mean that
        language independence becomes easier.  With regard to (B), 
        that would mean, for example, that we could theoretically
        write new pieces of Swarm in alternative languages (e.g. Java), 
        or rewrite old pieces.  It also means that it is easier for
        users to write simulations written in languages other than
        Objective C.

3.  Ease of learning

    With Swarm 1.2 there is a simple rule for using any library: 
    Include the module include file and declare objects that conform the
    documented protocols.  

PJ> And I don't see a need in particular under Windows to redesign the
PJ> libraries.

This is the basically true for the Tcl/Tk interface, yes.  However,
there have been major (although mostly invisible) changes made
throughout Swarm to facilitate the AWT front end.  It wasn't so much a
question of "redesign", but more a matter of moving inappropriate use
of Tcl/Tk things (which, sadly, were scattered everywhere in Swarm),
to the tkobjc library, and then abstracting away enough to do the same
thing with AWT.  The GUI interface will surely need more
generalization when AWT work continues...


                  ==================================
   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.
                  ==================================