Re: Add a predefined symbol __NEXT_RUNTIME__ to ObjC

[Nicola Pero <nicola at brainstorm dot co dot uk>]

> >>One of the little peculiarities of GNU Objective-C is that it supports
> >>two incompatible runtimes, the original "NeXT" runtime, and a later
> >>workalike called the "GNU" runtime.  The two runtimes actually have
> >>different user-visible API, and it's been a longstanding wishlist
> >>item to provide a way for source code to know which is in use.  This
> >>patch does that by using all the nice new predefine mechy to define a
> >>__NEXT_RUNTIME__ macro, and includes a sample usage in one of the test
> >>cases that has been failing on Darwin for some time.
> >>
> >>Since there may be better ideas about how to accomplish this, I'm going
> >>to let this sit for a day before committing.  (If anybody is wondering,
> >>I chose __NEXT_RUNTIME__ instead of __GNU_RUNTIME__ because it's the
> >>exceptional rather than the default situation.)
> >>
> >
> >Though I have no problem with the patch itself, would it not be
> >sensible to modify both runtimes such that both these functions
> >
> >>! #ifdef __NEXT_RUNTIME__
> >>!   selname = sel_getName (selector);
> >>! #else
> >>!   selname = sel_get_name (selector);
> >>! #endif
> >>
> >
> >existed in both?  If they are as functionally equivalent as this patch
> >implies, it would be a matter of a five-line addition to each, and
> >would improve code portability.
> >
> Unfortunately, this is just the tip of the discrepancy iceberg;

Yes :-)

Just mapping a few function names would not help much ... might actually
be more confusing than helpful unless some more deep merging/syncing is
done... the two runtimes are different - in the internals, and, more
importantly for the end user, in the API ... not just because the naming
convention for functions is different, but because some parts of the
runtime are really different.


> It is actually an interesting open question as to whether the GNU
> and NeXT runtimes could be merged somehow.  The NeXT runtime
> has hooks for asm-language acceleration for instance, but the GNU
> runtime is known to be more portable.  Although the runtime APIs
> of both are exposed and different, the user base is not so large
> that there wouldn't be some interest in changing sources to be
> able to take advantage of a merged runtime.

Changing sources might be quite a lot of work, but you are right that most
end users are shielded from the runtime details by the base library they
use on top of it - the Apple Foundation Kit on OS X and GNUstep base on
everything else - both of which claim to implement or be derived or at
least inspired by the OpenStep specification, and so share a common design
and API core.

The only users actually using the runtime directly are the 'advanced'
users (implementing bridges to other languages or advanced tricks in the
OO machinery), who normally/periodically advocate a merging of the
runtimes and so might actually not complain too much for the process :-)

I think there is a lot of interest in merging the runtimes.  The benefit
of having a single standard API for the ObjC runtime on all platforms
would be great.

In fact, some sort of 'standardization' process (even if not with all the
formality of ANSI etc) for the language would benefit all its users and
vendors, and at the moment the most 'unstandardized' area is the runtime
library, because we have two main different designs/implementations.

'Standardizing/merging the runtimes' would require discussing and agreeing
the way to do it (including the API etc), and then the details, and then
actually doing it :-) and might look like a long and painful process - but
I am definitely in favour of going this way if we have the opportunity to
do it.

There are some basic conditions I think - a merged runtime would need to
be part of the official GCC distribution, under a suitable GNU license
(such as the one used by the GNU ObjC runtime at the moment, or maybe one
slightly weaker such as the LGPL).  I don't know what Apple attitudes are
in this area, but the GNU ones are traditionally pretty clear, so a
standard GNU license is an essential prerequisite for any discussion on
the matter. :-)

I also think that portability would need to have quite a high priority for
any ObjC runtime library shipped with GCC.  Generally I think a very
portable ObjC runtime means ObjC is available on more platforms, and it's
very good for the language.  It's worth the occasional loss of a very few
cpu cycles on the mainstream platforms.

And, of course, it would be nice/essential to have the API well-documented
as an 'informally standard' open specification of what an ObjC runtime
library should be like nowawadays/in the future.

Producing a first draft of such a specification could actually be the
starting point of the work; the new merged runtime would become the
reference implementation - and it would be a single standard runtime
available on all platforms where the ObjC compiler runs.  Wow - now that
would be /cool/. :-)