[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Commit some Additions to a Gnustep file
From: |
Philip Mötteli |
Subject: |
Re: Commit some Additions to a Gnustep file |
Date: |
Mon, 3 Mar 2003 01:17:07 +0100 |
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