> > 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.
Cocoa is not opensource code. So you can't do
that.
....... > >>> That sounds to me like what I would
call glue
Now you are writing what looks to me like glue. object_message_send_a_la_GNU(...) would be a glue
code function written in pure C or any language other than Objective-C
Currently it does not exist. Would you like
to write it?
> So in order to adapt to your runtime, you just
wrap a runtime function
> into a method like this :
This is exactly what I have been talking about all
the time. I had understood you to write that this could be achieved
without writing any pure C functions.
> > 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.
So all you need to do is write them. I am certainly
not a good enough C programmer to do that.
> 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.
Would you like to share this 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 are the functions involved?
> What you actually want is to hack a bridge between
the two runtime
> systems. Yet another hack, after the delayed construction of objects.
Not at all.
> Instead, what I propose is, to clean the kit
up. Focus on Swarm and
Which kit? You have lost me here.
> 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.
A very laudable objective, but the mods made to the
runtime to introduces phases had an important motivation from the modelling
perspective: To allow the charaterisitics of objects to be decided at runtime
according to the state of the model. This makes lfe easier for the
modellers, which is the purpose of the Swarm code in the first place.
> >> 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
Those who know much more than me say that it cannot
be implemented on the GNU or Apple runtimes. I think your description
of the mods as a patch is misleading. It is really a feature extension
we want, not a fix for a problem. There is nothing about ths that
is not object oriented. It just extends the possible repertoire of
behavours for an object. There is nothing in the extenson that should
break existing code.