Re: State of Swarm on Mac OS X

[moetteli]

Am Sonntag, 22.09.02, um 02:56 Uhr (Europe/Zurich) schrieb 
address@hidden:
> > > 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.

Of course not in the case of Apple, but in the case of Gnustep. And 
apart from that, that's the reason, why I said that if you don't have 
the source, you set the runtime flag of the compiler to the one of the 
binary libraries.


> >  [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);
>
> .......
> > >>> 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?

No, 'object_message_send_a_la_GNU()' is the official runtime function 
for sending a message (I just don't have the official name handy). It 
is not written by me. This translation is made by the compiler.
Perhaps I help you, when I tell you a short fact about the history of 
Objective-C: ObjC has first been just a few Perl scripts, that 
translated all ObjC special expressions into pure ANSI C. So those Perl 
scripts translated

[anObject aMessage];         into          
object_message_send_a_la_XY();

Now, if you have the Gnu-runtime-flag set, a message is translated 
into, what I call here 'object_message_send_a_la_GNU()' and if you have 
the NeXT-runtime-flag set, into 'object_message_send_a_la_NeXT()'. 
Without any hacking, glueing, patching or addition to anything.


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

All (except the IVars part) of the above mentioned methods are one 
liners. Few things are easier. And anyway their already offered in both 
important foundation kits, that we should use with Swarm...


> > 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?

No problem. But as I said, they're already there. We just have to use 
them instead of directly calling the runtime functions.


> > 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?

Just replace all the direct calls to the runtime with equivalent calls 
to those methods.


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

Well, you said automatic translation between the messages coming from 
Swarm and going to Cocoa. Also by calling it glue. to glue means 
glueing two or more things together. And I try to explain you, that we 
don't need that, if we compile both with the same flag, which could be 
a problem, because in Swarm we can't just switch the flag, because it 
has direct calls to the runtime, which are of course runtime specific. 
And as a solution I proposed to remove all those direct calls with 
calls to the already offered wrapper methods.


> > Instead, what I propose is, to clean the kit up. Focus on Swarm and
>
> Which kit?

Swarm.


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

Yes, I do not put that on doubt. I just hope we could keep that 
functionality without hacking the runtime.


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

Well the problem we have here, is that Swarm is not portable, though 
there's an Objective-C compiler on more than 26 different platforms. 
Why isn't it portable, though the Objective-C specification/grammar is 
the same on all the platforms? It's because somebody changed (you 
prefer saying 'extended') the official Objective-C definition/grammar 
for Swarm. Now we do need a compiler with that new Objective-C 
definition on all the platforms, we want to use Swarm or, we try to 
model that within the grammar of the official ObjC. That way, it 
wouldn't be a hack. But, I don't know if this will be possible.
But I don't think, we should continue the discussion here about the 
phased destruction/construction as long as I have no technical 
information about it. I don't like losing my time speculating.

But my initial questions remain: Are people interested in replacing the 
foundation objects of Swarm with the Gnustep/Apple foundation objects? 
And are they interested in cleaning up the code, the way, that direct 
calls to the runtime are focused in just one location?


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.