Swarm Design Philosophy

[Paul Johnson]

Dear Everybody:

When I saw Marcus's notes about Swarm 1.2 (below), I started to wonder
about the direction of the project. 
I'm concerned that there is too much code revision purely for the
sake of code revision.  I see no new functionality in Swarm by converting
the classes to protocols, I just see a lot of broken code.  The change
from Swarm 1.0.3 to 1.0.5 was the first time we saw this.  I can change
code to match, but I don't see a modeling justification for the changes.
What can I do now that I could not do before?  Are we just tidying up
past coding mistakes/poor design?  If so, what is the benefit?  Heatbugs
ran before just fine, before and since.

As far as I can see, the only significant increase in functionality in
Swarm has been the ability to save window positions.  Granted, the version
1.1 ability to compile under Cygnus in Windows was a step ahead in many
respects, but I've decided to stay in *nix, so this is not so important to
me.  And I don't see a need in particular under Windows to redesign the
libraries.

I don't mean to attack anyone or start a flame war.  I'm just expressing
the opinion of a non-computer programmer who tries to use Swarm to build
models.  Rather than having the libraries rewritten to do the same things
in new syntax, I'd much rather have documentation, not just technical
descriptions of what each method in the libraries is, but Usage Guide 
material with more examples.  

Since I'm not a programmer by training, I realize my question seems
naive.  It just seems to me that existing libraries and code syntax
should not be changed unless there is some fairly immediate justification
in applications.  If I decided to try to write a "Beginners Swarm Usage
Guide", as I tried to do three months ago, I would again be put off by the
feeling that changes in the libraries would render the work moot.


Paul Johnson 

On Tue, 28 Apr 1998, Marcus G. Daniels wrote:

> 
> Yes, we are converting all the libraries over to protocol interfaces.
> 
> With Swarm-1.2 folks will either have to eliminate use of statically
> typed things like EZGraph *, or include the relevant interface file.
> 
> Previously, analysis.h and space.h were made up of all the includes
> of the respective libraries.  Now they are protocol definitions, just like
> defobj.h, collections.h, activity.h, and gui.h.
> 
> This means that you should change the types of the EZGraph's, etc.
> in your application header files to be like:
>  
>   id <EZGraph> foobar;
> 
> instead of:
> 
>   EZGraph *foobar;
> 
> For temporary portability, you can just use a generic object, e.g.
> 
>   id foobar;
> 
>                   ==================================
>    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.
>                   ==================================
> 

Paul E. Johnson                 address@hidden  
Associate Professor             http://lark.cc.ukans.edu/~pauljohn
Dept. of Political Science      Fax:   (913) 864-5700
University of Kansas            Phone: (913) 864-9086
Lawrence, Kansas 66045


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