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

[Willem Rein Oudshoorn]

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.  

But this really touches at the goal of GNUstep.  Are we
trying to build a free OpenStep implementation with 
MacOSX extensions added, or are we aiming at a 
MacOSX compatible framework.   

I see the advantage of the second approach, but for me there 
are a few problems with that:

- Apple is a moving target
- Some extensions can not be implemented 
- Some changes to the API do not make sense (at least to me).

On the third point, at the risk of sounding like David Stes, 
it looks to me that changes like raising exceptions on nil
arguments are done from a JAVA/C/C++ like background.

In conclusion, my personal opinion is that it is better to
formulate the goal of GNUstep as:


- Default behaviour is an implementation of OpenStep,
  aiming for a stable API that is derived from 
  version xxx of OpenStep.

  Additions here are OK as long as they fit in with
  the philosophy of OpenStep and they are really additions
  and do not change the behaviour.


- MacOSX compatibility mode that is allowed to break
  compatibility with OpenStep but will try to follow
  the MacOSX API.


When fixing my patch I will try to think about how to 
arrange this, and hopefully write some documentation
on the subject. 


Wim Oudshoorn