[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: |
Sat, 21 Sep 2002 05:53:19 +0200 |
Am Freitag, 20.09.02 um 08:30 Uhr schrieb address@hidden:
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 will say again - this will NOT work. The C call to pass a message
to an
object via the Next/Apple library is a different function from that
used
by the GNU library.
Exactly.
If you compile a program with the -fgnu-runtime flag
it is simply impossible for that code to call a Cocoa object, because
it
would be using the wrong 'language'.
Only, because you have a compiled version of that object. If you have
the source, then just compile it with the same flag and they
communicate without a problem.
Conversely, if you compile with the
-fnext-runtime, then the code cannot access a Swarm object.
...if you use a compiled version of Swarm. All the parts of a program
have to be compiled with the same flag. ALL, even the very most minor
little ObjC-library you include into your project.
You achieve this either by having the source of everything (then you
can freely choose, what flag you want to use) or by compiling the part
of the software you have the source for, with the flag, your binary
libraries have been compiled with.
As long, as you don't call the runtime directly (as you see in the code
example below), the compiler will translate ALL your messages, like:
[anObject aSelector];
into (depending on the flag):
object_message_send_a_la_GNU(a, list, of, arguments);
or
object_message_send_a_la_NeXT(a, slightly, different, argumentlist);
The syntax on the ObjC level remains the same, indpendent of the
runtime. It's the compiler who translates them into the proper runtime
function call.
But the moment you call them directly (read: C-function), of course,
the compiler won't transform this any more to your chosen runtime-flag.
It will take the function as is.
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.
Every call to an object method is a call to the runtime system.
Of course, but if it's not directly visible in your code, the compiler
will translate it to the fonction, you have chosen with your compiler
runtime flag (-fnext-runtime/-fgnu-runtime).
So in order to adapt to your runtime, you just wrap a runtime function
into a method like this :
- perform:(SEL)aSelector
{
#ifdef GNU_RUNTIME
object_message_send_a_la_GNU(a, list, of, arguments);
#else
object_message_send_a_la_NeXT(a, slightly, different, argumentlist);
#endif
}
And you're ready for both runtimes (if you only use this method in all
programs, when you want to use object_message_send()).
Now, if you call these runtime C-functions
(object_message_send_a_la_GNU or object_message_send_a_la_NeXT)
directly yourself and they are distributed all over your program, you
gonna have much more work to clean it up. But if you called everywhere
(where apropriate) in your program the wrapper '-perform:', you just
have to change it at one place (the way, I showed it up there).
That IS
the problem. You cannot quarantine them in one object.
What is needed is a C library. The object implementation in the Swarm
code could invoke an NSObject method by making a C call to this library
that then makes a C call into the Apple runtime. It has to be done in
a
pure C program so that the compiler generates no Objective-C runtime
calls
when it is compiled.
It would be similar to the avcall/mframe stuff in Swarm.
You can offer for every runtime function a wrapper like the above.
There are not many, that make sense:
class_from_name() -> Category to NSObject:
-(Class)classFromName:(NSString*)aName
objc_message_send() -> NSInvocation-object or
-> Category to NSObject:
-performSelector:(SEL)aSelector
superclass() -> Category to NSObject: -(Class)superclass
pose_as() -> Category to NSObject:
+(void)poseAs:(Class)aClass
ivars -> Category to NSObject:
-(NSArray*)iVars
...some bundle functions.
I have already implemented all of those methods myself. I have
implemented it myself, because I hate being non object-oriented. So I
create an OO wrapper (method or object) and from now on, I'm perfectly
OO. Makes life more easy.
Now in all the above methods, where you can't resist to call the
runtime function yourself, you make an #ifdef. And it's done. From now
on your code is runtime independent (if you use your wrappers in your
code).
Almost all of those wrappers are already implemented in Gnustep and
Apple's Foundation. So you just have to use them. But that's the
problem: Swarm is quit old...
What you actually want is to hack a bridge between the two runtime
systems. Yet another hack, after the delayed construction of objects.
Instead, what I propose is, to clean the kit up. Focus on Swarm and
doing it on the OO level, not on the runtime level. That way, we can
1. reuse, what others already implemented and debugged in their
foundations,
2. being perfectly portable between the runtime systems,
3. have a cleaner code with all the advantages this brings.
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.
This problem is administrative not technical. You would need to
pursuade
the GNUstep maintainers to include it in the source tree.
That depends. If it's a patch to the runtime (what I'm afraid of), we
would have to ask the GCC maintainers. If its implementable with
Gnustep/Apple's Foundation, without touching their source, we do not
have to ask anybody. So far I do not know, how this is achieved. I have
to analize this closer. Except if somebody can explain it to me here.
;-)
Regards
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