Re: GNUstep and MacOS X Port Effort

[Marcus G. Daniels]

> It no longer makes sense for Swarm to roll its own Objective-C runtime
>
> b.  To facilitate the above, Swarm should not make any C calls into the 
> 'runtime'.
I don't think you'll have much success re-implementing the phase stuff 
without using C interfaces.
There isn't much use of C functions, but there is liberal use of 
Objective C runtime C data structures to accomplish that.  

> c.  The phasic object system should be preserved and possiby elaborated.
In it's current form it is good for nothing except historical 
continuity.  But that's the rub, either replacing Swarm with something 
new and ambitious and interesting or cleaning-up loose ends on the old 
version.  I don't see the benefit of larger codebase changes; there are 
too many complications.

There is substantial complexity in the Java design & implementation to 
support phases.  I believe it is fully debugged now, and there would be 
similar complexity to graft it into Apple's Java scheme.  It's not a 
Java issue or Objective C issue but rather an issue of grafting dynamic 
typing idioms on to a static environment.

W.r.t. to runtime compatibility, it would be much easier and more direct 
to start
macroifying all instances of Objective C runtime (functions and data 
structures) and then, as each instance of the GNU Objective C API  (or 
pseudo-internal item) was encountered, investigate an alternative in the 
Apple runtime (or, if necessary, propose something new [to Apple]). 
When that was done, Swarm would only use these macros and there could 
be a configure-time ifdef to select
between the build environments (or adapt dynamically by checking a flag).

As I see it there are incremental changes and there are non-incremental 
changes.  defobj, collections, and the activity library are 
interdependent.  If you want to think about making them clean to use 
with Cocoa you are essentially talking about replacing them.  If you 
replace then the rest can be dumped with less work.

The incremental approach to is doable, but the result will be something 
that won't internally leverage external libraries for objects and 
collections.  

> d.  The GNUstep/Cocoa classes should provide the GUI eliminating 
> dependence on Tcl/Tk/BLT
>  
There was just another major release of Tcl/Tk.   I'm skeptical that 
GNUstep is a step forward in terms of stability.  The same approach 
could be applied to the `gui' interfaces.  The advertised Swarm gui API 
is ad-hoc and has many Tkisms, but it could be adjusted for the sake of 
other GUI toolkits.  Abstract-out to subsume both..  

> e.  As many basic classes as possible should come from the standard 
> libraries, to maximise the benefit from work done by others.
It would be hard to change the activity library to use an external 
collections library.  There are many places that, for performance, Swarm 
directly dereferences Swarm linked-lists, for example.   activity and 
collections are very intertwined.

> a.  Marcus has observed that the purpose of the mframe stuff in the 
> runtime is to support the link between Java and ObjC.  GNUstep and Cocoa 
> already contain such a link.  Indeed Apple has put a lot of development 
> effort into this.  We should use this and scrap mframe which is a nasty 
> machine specific klugeTM.
Before throwing out such a committment, I would suggest identifying 
whether you really want
to support Objective C messages to Java targets, e.g. all the foreach 
stuff in Swarm collections and activity interfaces and then convince 
yourself that Apple has a good way to take apart messages into their 
arguments.  My guess is that they avoid the issue by forcing use of 
objects and have lots of no-and-single-argument methods, e.g. in the 
style of Interface Builder.  

However, I found that I never used the Objective C still message calls 
in scheduled stuff.  For serious modeling, it was way too slow to take 
apart calls and re-issue them.  The need for the feature was just 
pedagogical; a direct Java analogue to the Objective C style programming.  

> b.  Being totally Gatesophobic, I have no idea how this plays on Windoze. 
> Is there a workable Cygwin/GNUstep installation available?
>  
The main question is whether DLLs work.  DLLs have a convention for 
automatic access to variables _by call_ that the compiler & linker 
provides transparently.   The last time I experimented with libtool on 
Windows libtool did 99% the right thing, and I was able to link up Swarm 
and Objective C DLLs using libtool and run Java models.  (Swarm 
currently uses a modified dlltool and dllwrap.)  I'm optimistic that the 
DLL rules in libobjc and the DLL rules in Swarm can be dumped and a 
straight build of Swarm from automake-generated Makefiles is possible.

> d.  Method functions are incompatable with the above objectives as well as 
> being abhorrent to any OO believer.  They should be given a decent burial.
You mean the conversion of methods to their C counterparts?  As I 
recall, NeXT [Apple] used to have a very different Objective C runtime 
structure.  It may not be possible at all, but if it is there would just 
be a slight syntax change.  This optimization is not a huge win for most 
people, but it is enough that it outweighs the religious opposition.  ;-)

> f.  The root object of Swarm is Object which maybe can be built by 
> extending NSObject, which makes the above at least faintly plausible.
Swarm physically scans and regenerates method tables.  Further, it uses 
a completely different API for creating objects.   It doesn't look or 
act like NSObject except for the fact there are messages and 
dynamically-typed objects.


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