Re: Integrating Swarm and Cocoa on MacOS X

[W . Northcott]

address@hidden wrote on 26/09/2002 08:45:29 AM:
> We're very close now! So me too, I try it with a summary:

I might be close to understanding what you are saying.  That is not the 
same as agreeing with it.

As I see your approach you are looking at Swarm from the programmer's 
perspective, not the modeller's.
Swarm uses Objective-C, not mainly because of the possibility for code 
reuse, but much more because the object paradigm closely parallels the 
agent based modelling paradigm.  The language was modified to make things 
easier for the users for the same reason.  We would need some very 
compelling reason to make thing harder for modellers.

> > a.) There are basically two problems, why Swarm is that difficult to
> port:
> 1. Swarm uses direct calls to the runtime functions.
> 2. Swarm modified the runtime itself (the 'mods').

Swarm is difficult to port because it uses bleeding edge or even modified 
versions of the gcc compiler, and the foreign function call system.  (That 
is writing from personal experience) Although I think I now understand 
that much of that can be dispensed with.
The problems you list don't make it hard to port, they make it hard to 
integrate with an Objective-C based system.  There are only two of these - 
GNUstep which is a very limited audience and MacOS X which is new.

> Problem 1 is easely correctable, by cleaning up the code in order to ...
> Problem 2 is a difficult one, because it not only leaves the ObjC  ...

Outside of MacOS X these are not problems.  AFAIK only defobj makes calls 
to the runtime, which is as it should be.

> > Now, by removing the actual foundation objects from Swarm and 
replacing
> them with Gnusteps, we would help, problem (a.1) and solve all of (b).
> It remains problem (a.2), where I can't comment yet.

You would also break every line of Swarm user code ever written, which is 
not a minor problem.

> Now back to Bill's post:

> > already included a mechanism for messaging and receiving responses 
from
> > 'remote' objects.  (Objects on another computer, or another app on the
> > same computer.)  The classes include NSConnection, NSInvocation etc. -
> > see
> >  Apple's distributed object documentation at:
> > http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/
> > ProgrammingTopics/DistrObjects/index.html#//apple_ref/doc/uid/>
> > 10000102i
> > (Phil - Have I got this right?)
> Well, this is just one of the features, offered in those foundation
> libraries. It's way cool having it, but not necessary. It's like keyed
> encoding, normal serialisation, and many, many others. Many people will
> perhaps never use that. But it opens a door to many applications, e. g.
> a distributed version of Swarm or a threadsafe version, etc.

This is about the only thing from this discussion that I can see as 
useful.  The GNUstep libraries seem to include the same classes as the 
Apple ones.  So perhaps they could fairly easily be pulled into defobj to 
let a Cocoa process communicate with a Swarm process on the same (or 
different) machine, and remove the need for nasty low level glue.

In summary, I am now fairly convinced that the cost and difficulty of 
getting away from the modified runtime and Swarm specific defobj and 
collections libraries are not justified.  There are other ways to get 
integration with MacOS X, while on other platforms there would be little 
benefit and almost certainly much detriment for the users.

Bill Northcott

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