Re: State of Swarm on Mac OS X

[moetteli]

Am Donnerstag, 19.09.02 um 01:52 Uhr schrieb address@hidden:
> Bill Northcott wrote:2.  To enable the splitting of object creation 
> and destruction into
> phases, which introduces runtime flexibility important to the 
> modellers.
>
> Apple say they have done a lot of work on 1..

This seems to be the compiler flag for the runtime.


> 2.  To enable the splitting of object creation and destruction into
> phases, which introduces runtime flexibility important to the 
> modellers.
> 2.  Is regarded as rather important for the users.

I will have to have a look at that.


> > The same is valid for me. So that's perhaps the reason, why I don't 
> > see
> > yet, why the different message dispatching call is such a huge 
> > problem.
> > This function should only be called in one object like (Cocoas)
> > NSInvocation.
>
> If this object is compiled with the Next runtime flag (to communicate 
> with
> Cocoa objects), it would not be possible to invoke its methods from a
> Swarm library compiled with the GNU runtime flag.

Of course, but  just compile everything with the same runtime flag.


> I
> really recommend Scott Christley's summary.  He knows much more about 
> this
> stuff than me.

I read it. That's one reason, why I post.


> > Or differently said, as long as you encapsulate all the
> > tinkering with the runtime system into a separate object (what OO
> > actually demands you), you could only make a few precompiler 
> > directives
> > to solve the problem.
>
> That sounds to me like what I would call glue

Well, you can call it as you wnat of course. But in OpenStep/MOSX, we 
have methods in NSObject (performSelector, superclass, poseAs,...) and 
in separate objects like NSInvocation. Those are all calls to the 
runtime system, but by making it part of an object, you have it just in 
one place.


> and it would need to be in C
> not ObjC.

Of course, because the runtime is writtten in C. Couldn't by otherwise, 
because you need it to render C object-oriented (you would have a 
chicken-egg problem).


> > And there's another thing, that bathers me/I would like to propose: 
> > Why
> > keep and maintain Swarm's own foundation classes, when you could go
> > GNUstep? And by doing that you gonna have some more programmers for
> > free working indirectly for Swarm AND you get MOSX compatibility? 
> > Apart
> > from that, Swarm could use additional stuff like Distributed Objects
> > and thelike.
>
> It could be great, but you would need to get the GNUstep people to 
> accept
> the mods mentioned above.

Well if this phased creation and destruction of objects could be solved 
in OpenStep, it's automatically also solvable in Gnustep. Because on 
MOSX I don't even have the sources. But I have to have a closer look.


Re
Phil


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