Re: [PATCH] accept null selector for respondsTo...

[David Ayers]

We seem to be talking about different "code".  Let me try to explain 
what I mean with the current example.

If, for example base used #ifdef API_Compatibility OSX to switch between 
behaviors (i.e. raising on NULL selectors or not), then compiled library 
will either  implement one *or* the other behavior, depending on how it 
was compiled.  If this executable is part of the "GNUstep.rpm" which is 
installed by a user, then any "other code" the user installs (read your 
project) will use this behavior of base.  (i.e. will raise if these 
methods are called with NULL selectors or return nil/NO.)

If GNUstep always defaulted to a more tolerant behavior, "other code" 
won't be affected by it.  If the decision on whether to assert stricter 
behavior (to locate errors or insure OS-X compatibility at runtime for 
the "other code") was postponed to runtime, then maintainers of "other 
code" could work on OS X compatibility at a time decided by them, while 
still being able to use the most current version of base.

Yet non-the-less, any code should *try* to be implemented using the 
strictest assertions.  (In this case it would simply mean, to verify 
that these messages are never invoked with a NULL selector.)  But 
implementing it tolerant in base when the default isn't set, would allow 
projects that don't handle this *yet* to just to keep working with the 
current base.  Yes, these projects should still update, but they should 
do it when they decide.

What I would like is that GNUstep libraies use the most tolerant 
behavior possible by default, but allow

(a) a compile time switch for headers to expose only the 
methods/functions of a defined API.  (This only applies to 
declarations.  The implementations remain.)
(b) a runtime defaults, which enforces a specific API behaviour constraints.

I think (a) is pretty much what we already have in many of the GNUstep 
libraries.  (Well maybe we don't have swithes for the different versions 
of the API, but I might look into that one day.)

But the compiled library should support all (or as many as relevant) 
behaviors of the supported API's and allow some runtime mechanism to 
decide which one to use.  This way we can have one set of RPM's which 
implement the different API's.

Now if your code choses between API's with #ifdefs, you'll need an rpm 
for each API unless you only support one API per "plattform".  If you 
like, you could assert that your users only use OSX_Compatible on Apple 
and you package that in a *.dmg and that your users use API GNUstep on 
GNU/Linux, BSD, Windows or what have you, and they get packaged in some 
coresponding *.rpm, then that is your decision as the project maintainer.

But I would like GNUstep to be able to decide at runtime rather than 
compile time, which API it implements.

Cheers,
Dave