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

[Jeff Teunissen]

Willem Rein Oudshoorn wrote:
> David Ayers <d.ayers@inode.at> writes:
>
>
> > 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 agree here with David and Richard.  So I will modify the patch
> to behave like this.  
>
> Also, I really think that we should not see this as a temporary
> measure.  Like a backward compatibility switch that will be 
> removed as soon as all OpenStep applications / core itself,
> are modified to support the new behaviour.  

And when the new behavior is clearly wrong (as in this case)?

Mac OS X compatibility is sideways, not forward.

I can see a runtime default for optionally choosing the Mac OS X-compatible 
behavior -- it's a corner case that should be handled on the chance that a 
developer cares about OS X compatibility. However, the new behavior is 
clearly wrong from both a historical reference and on the principle of being 
generous in accepting potentially-spurious input.

Passing a NULL selector into (for example) NSMenu is a well-known thing, and 
perfectly acceptable because the callee should always check its input before 
operating on it. Only when there is no possible "reasonable action" should 
an exception be raised.

--
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/