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

[David Ayers]

Pete French wrote:

> > > 2. Support both behaviors, with the tolerant behavior the default and the
> > > exception raising behavior turned on by the existing GSMacOSXCompatible
> > > user default.
> > >      
> > This would be my personal preference, as this would relieve other 
> > GNUstep Apps/Libraries/Frameworks/... of dealing with the "most recent 
> >    
>
> Doesnt this mean that you end up with some apps needing this enabled to run,
> and others needing this disabled ? Thats incredibly frustrating for users
> I would have thought.
Please no, that's not what I'm aiming at.  I'm saying some apps will 
work with this disabled and some will work with this either disabled or 
enabled.  Right now, when core changes the API to fit OS X in this way 
(effectively adding constraints), then a lot of GNUstep code (and code 
ported from previous OpenStep implementations) breaks.  I find *this* 
frustrating.  But I could imagine other API changes that might me more 
complex to handle (just haven't tough about it hard enough yet).

> > to.  But I think that we shouldn't force *all* projects to update to the 
> > newest OS X API just to work with the current version of the core libraries.
> >    
>
> Agreed, but theres no harm in a small amount of ifdef's in life either on the
> part of developers. Id prefer to know there was only one API on each system,
> even if they happen to be different between the two, rather than having to
> code either enforcing the behaviour or programming for both eventualities.
>  
Actually I consider #ifdefs to be very bad in this case, because you 
come up with different behavior in the binaries.  This will be very hard 
to handle for RPM's and other packaging methods.  You would have to 
differentiate which libriaries, compiled with different compatiblilty 
defines your code is dependant on.  I think any compatiblity differences 
should be handled at runtime by some mechansim, and the standard default 
mechanism, defining which API behavior to use, seems fine to me, as it 
can be tuned on a per executable basis.  A tool or app could even set 
this to "it's" mandated value if necessary.  This shouldn't be done for 
any shared code like libraries, frameworks or loadable bundles though.  
These should be written tolerant to any default but I would find it 
acceptable for them to only follow the "GNUstep" behavior, which is 
generaly the more tolerant behavior anyway, until users request (or 
submit patches) for these projects to also work on OS X.

Is this clearer now?

Cheers,
Dave