Re: Commit some Additions to a Gnustep file

[Philip Mötteli]

Hi


Am Sonntag, 02.03.03, um 08:15 Uhr (Europe/Zurich) schrieb Richard 
Frith-Macdonald:
> On Sunday, March 2, 2003, at 12:16  am, Philip Mötteli wrote:
> > Am Samstag, 01.03.03, um 07:59 Uhr (Europe/Zurich) schrieb Richard 
> > Frith-Macdonald:
> > > On Friday, February 28, 2003, at 11:02  pm, Philip Mötteli wrote:
> > I actually don't see any reason to have many people using this code. 
> > I just see, that many people have already started to implement the 
> > same things. So instead letting future user continue implement it, I 
> > commit it and we have some common place, where people can just 
> > complete, what is missing and not reimplement it again and again.
>
> To me, 'use' means that they will call if from their code, add 
> improvements to it, etc rather than re-implementing it.

That's the same meaning to me.


> If code is added to the extensions library, it's likely to be 
> reimplemented  in the additions/base libraries or elsewhere
> on an individual basis.

Why? Don't people look at what's already there? I mean, Gnustep base is 
OpenStep. The OpenStep definition has nothing prescribed for runtime 
conversions. So in my eyes, we shouldn't force people to link with that 
code. Especially, because it shouldn't be needed very often.


> > > GSObjCRuntime.[hm]
> >
> > It should be a file, that deals with conversion of runtimes.
>
> GSObjCRuntime.[hm] is all about providing a common set of runtime 
> features, by hiding/converting
> runtime-specific features to a standard form.  This is the area 
> currently being developed to provide
> runtime capabilities independet of the actual runtime in use.

Ah, I understand. But this file is already starting with the idea, that 
somebody writes a new program and uses the runtime functions defined in 
that file, instead of calling the specific functions, defined for one 
runtime. That way, he would remain open for both runtimes. Am I right?
Me, I try to port the OmniFrameworks to Linux. Those frameworks have 
been written, using the NeXT runtime functions. So, what I need is, to 
find a compatibility layer, that implements the NeXT runtime calls, by 
using the GNU runtime calls. I can't choose myself. Omni-Group has done 
that for me.


> > > and/or  objc-gnu2next.h
> >
> > That's unfortunately the wrong direction. I would need 
> > objc-next2gnu.[hm]. Apart from that very few things are already 
> > implemented there. In contrast to objc-runtime.[hm], many things are 
> > already there and both directions are covered.
>
> Are we talking about the same files at all?  Last time I looked 
> objc-gnu2next.h covered pretty much the same ground as objc-runtime.h 
> and objc-runtime.m just implemented a few of small functions (mostly 
> duiplicating functionality in the base library).

In one point you're right: I just made a fresh CVS check-out and the 
size of both are big.


> For example, getting an instance method ... both header files define 
> class_get_instance_method to be class_getInstanceMethod so you can
> use class_get_instance_method irrespective of the runtime in use, and 
> neither defines a mapping in the other direction.

Your half right here: Yes, in your example, both files offer the same. 
And you're even more right, because even 'objc-runtime' doesn't offer a 
lot more for my case. But the separation between the runtimes is 
already there: You have a section GNU_RUNTIME (which doesn't contain a 
lot) and a section NeXT_RUNTIME (which contains much, much more). And I 
need a section GNU_RUNTIME, because I'm porting to the GNU runtime. 
This section is entirely missing in both of the other files. So either, 
we create sections in those files, and frankly, I don't think this 
would belong into GSObjCRuntime, or we put it where there are already 
sections and the name is sufficiently open to contain both directions.
But basically, it doesn't matter to me, where we put it. So as a 
Gnustep newbie, I prefer following your decision. For me, what counts, 
is that it will be integrated somewhere.


> > If everybody does agree to put it into objc-runtime.[hm], we don't 
> > need FSF intervention. Apart from that this first commit wouldn't be 
> > more than 14 lines.
> >
> > If that's ok, how should I proceed now?
>
> Perhaps it would help to post the actual code.

Here it is:

NeXTRuntimeCompatibility.c
Description: Text document

NeXTRuntimeCompatibility.h
Description: Text document

.


Re
Phil