Re: How to check that selectors exist

[Nicola Pero]

> >>  4. it's completely inconsistent with how checks for functions and
> >> variables and methods and everything are handled/done, since normally 
> >> when
> >> checking the compiler never 'looks ahead', while for selectors it 
> >> would
> >> do; this might look like an improvement at a first glance, but it 
> >> actually
> >> confused me a lot the first time I tried to use it, since the golden
> >> standard rule that 'everything must be declared before being used' is 
> >> no
> >> longer valid, but a more complex, selector-specific, rule is used.
> >
> > This is the main point for me, since I think selectors should be 
> > handled like functions in this respect, and it's just good practice 
> > (sometimes necessary!) to declare a function before you use it.
> 
> Do you do much Objective C programming?

:-) 

Oooppps.

Asking the GNUstep chief maintainer if he does much Objective C
programming is quite funny :-)  He definitely does.


> Good practice in Objective C is not the same as good practice in C++.

My - and Adam's - comments - where precisely based on a very extensive
practice of Objective C in a free software environment with lots of
contributors concurrently working on the same codebase.  You need to
declare stuff always, and clearly, in such an environment.  Even private
methods.  Otherwise you end up with unreadable code.

 
> Two observations.
>    (1) I assert that very few organizations have as much experience
>          with large bodies of Objective C code than Apple applications
>          groups.  I claim that they have had more opportunity to learn
>          what good Objective C practice is than most other groups out
>          there, and that their opinions about good practice should be
>          taken seriously.

Yes - their opinions should be taken seriously.  So do ours.

Btw - we didn't have much explanation of what their opinions are and why
they like the warning in that way - just that this was the proposed
warning, and doing elsewhere would cause warnings for their code.


>    (2) Devang's original patch is one that will catch probable errors.
>          Nicola's proposed change will catch errors and will also catch
>          violations of one particular idea of good practice.  I believe a
>          closely targeted warning about probable errors is a good idea,
>          and that we should not entangle it with the good-practice
>          warning.  If we want a forward-declaration warning, it should be
>          separate.  (I can certainly see that some Objective C programmers
>          may have reasons for using forward declarations consistently,
>          and that they'd find it useful if the compiler helped them with
>          their stylistic choices.)

Ok - thanks - I do appreciate comments on the actual matter :-)

I think/hope separating a -Wselector which checks the selector table at
the end of compilation (which I think allows very clumsy code - but I
understand it might be my and Adam's and other GNUsteppers' opinion only)
from a more strict -Wundeclared-selector which checks each selector
against declared ones when the @selector() is found (which instead
enforces good practice - or maybe 'one particular idea of good practice' -
the GNUstep's crew one in that case) might make everyone happy.