Re: Commit some Additions to a Gnustep file

[Richard Frith-Macdonald]

On Monday, March 3, 2003, at 12:17  am, Philip Mötteli wrote:

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

Sometimes they don't.  More often, they don't want to create 
dependencies on additional libraries in their software,
especially ones which are unlikely to be present in standard setups.  
Also, in general FSF policy is that GNU applications
should not have dependencies on non-standard, non-gnu libraries... so 
if you are writing an app to be contributed to
GNUstep, you won't design it to depend on a non-gnu library unless you 
really have to.

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

That's why the Additions part of the base library can be built 
standalone ...
> > > > 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?

Yes.

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

I see.
It still might be worth actually porting ...
I recall Apple deprecating use of their runtime functions a while back 
... I'm not sure in practice that really means anything because I don't 
think they could get away with removing the current runtime 
functionality, but they might.
The other thing is ... look out for selector comparisons.  With the gnu 
runtime you must use sel_eq() to compare selectors but I think code 
using expecting the apple runtime often uses a pointer equality check 
... which won't work with the gnu runtime.

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

I agree.

> or we put it where there are already sections and the name is 
> sufficiently open to contain both directions.

I put some trivial reverse-mapping macros in the objc-gnu2next.h file 
... perhaps they will do what you need.