How to check that selectors exist

Nicola Pero nicola@brainstorm.co.uk
Tue Aug 6 01:50:00 GMT 2002


Hi,

there was a discussion on the gcc-patches@gnu.org mailing list recently
about adding new checks in the ObjC compiler.

The basic idea is to have the compiler check, whenever a @selector()
expression is found, that the selector is actually defined somewhere, and
issue a warning if not.  The warning would only be turned on by some -Wxxx
flag.  It would prevent a typo in a @selector() from causing a runtime
problem.

The patch proposed by Devang - from Apple - is to check the selectors at
the end of compilation, after everything has been parsed.  In this way,
even if a selector is implemented in an @implementation, but never
declared explicitly in an @interface, no warning is generated.

This looked good to me until I tried it out :-)

 1. it doesn't work with the GNU runtime and there is no obvious way of
making it work (because of the way selectors are internally handled by the
compiler, GNU ones are typed, while Apple ones are not etc);  so it would
be a next runtime only patch for now (and maybe for very long).

 2. the warnings appear at the end of compilation even if they refer to
lines much before - for example, a warning for selector unknown on line 8
might appear after warnings up to line 23456 have been emitted;

 3. the warnings disappear if the end of compilation is not actually
reached (for example, because of an error stopping the compiler before).  
I hate this because it means when you start fixing code from line 1
forward, when you finally got it to compile, new warnings appear for lines
you thought were now safe.

 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.

 5. it's inefficient compared to checking the @selector()s when they are
found.

So I think the right way of doing it is instead of making the check
immediately after each @selector() is found, which would work with the GNU
runtime, would be consistent with the compiler behaviour in all other
circumstances, would generate warnings at the right lines/time, and would
be efficient.

But there is a downside in this way of doing it - if you have a private
method in an @implementation which is never declared in an @interface, you
would get a warning if you try using a @selector() referring to that
method before the method implementation is found.  Devang thinks this is a
fundamental problem, because at Apple they often do this and he doesn't
want new warnings for existing Apple code.  My main point here is that
this code is not particularly well written, since in well written code you
should declare all methods in @interface before you refer to them,
supporting your @interface declaration with useful comments about what the
method is and does.  So I think it's actually good that the compiler warns
if you use a @selector() before the corresponding method is defined or
implemented, since it's helping in improve the quality of code.  It's ok
to have private methods, but not so much private that they are actually
obscure. :-)

So I've been opposing the patch :-) and trying to have it converted into
one which checks as soon as the @selector()s are found.

The discussion has been restricted, up to now, between me and Devang - too
small a group to get it right :-) - I'd like to hear comments from
everyone in this respect - any particular points in favour of the first or
the second way of making the checks ?

We are already very much on the edge of a flamewar, so *please* do try to
make mild and conciliatory comments even when having/expressing clear
opinions in favour of one of the two :-)

Thanks for any useful comments.



More information about the Gcc-patches mailing list