[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: State of Swarm on Mac OS X
From: |
moetteli |
Subject: |
Re: State of Swarm on Mac OS X |
Date: |
Fri, 20 Sep 2002 01:44:34 +0200 |
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.
Re: State of Swarm on Mac OS X, Ed Baskerville, 2002/09/24