Re: Making swarm use functions from other toolkits (Glib, GNUstep)

[Marcus G. Daniels]

AL> For the bulk of users, who'd rather not invest time with learning JNI
AL> (Java Native Interface) features I'd suggest spending time on
AL> implementing your model in either Java or Objective C, but not both
AL> `simultaneously' as it were.

Right, the point is just that if people really need Java interfaces
to legacy Objective C code, it's possible.  But it should be a measure
of last resort, since there are performance penalties and packaging
complexities that will obscure the clarity of a [new] model.  Of course,
in the real world, sometimes obscurity just must be endured.  But only 
very strange applications would need to ever make a JNI call.

AL> GCC is in the process of integrating link-level support with Java,
AL> which might allow this kind of coexistence, but that's not tested in
AL> the Swarm context as yet.  Furthermore, at some stage we may split out
AL> the protocol parsing stuff from Swarm, and make it generic enough so
AL> that it could handle third-party libraries, but again that's further
AL> down the track.

I guess I misread Paul, but I thought the spirit of the question was
whether Swarm data structures and Java data structures were directly
compatible at a high level, e.g. Swarm collection/activity things
would magically show up as
__fill-in-third-party-library-of-your-choice-here__.  That's not a
language issue, that's a question of potentially conflicting data
structure / library designs.  E.g. a Swarm Map and a Java hash table
won't have a one-to-one relationship; they're different things.

Link-level support is about meshing objects and messages together
at a low level.  The idea with this would to 1) eliminate the
involvement of Objective C message dispatching (fairly easy) and 2)
eliminate the multiplicity of native object types (hard).  Cygnus' GCC
Java project strives to integrate C++ and Java objects in compatible
low level data structures.  With the GCC Java compiler and their
native interface conventions, calling back and forth between C++ and
Java is like calling between C and Fortran -- almost transparent and
very fast.

Btw, we didn't create features for dealing with a multiplicity of
native languages object types because it was easier.  We did it that
way because with most languages and applications it is pretty much
impossible to unify the physical object data structures.  Doing that would
necessitate having influence over two project source trees.  Not going
to happen talking to Visual Basic, for example.

Anyway my sense is also that folks should stick with one or the other,
at least within a given Swarm.  An ObserverSwarm implemented in Java
and a ModelSwarm implemented in Objective C might have utility for some folks,
though.

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