Re: How to check that selectors exist

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

I'm not an Objective-C user, but I thought I'd wade in here anyway...

On 06-Aug-2002, Nicola Pero <nicola@brainstorm.co.uk> wrote:
> 
>  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).

I can't really comment on that...

>  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.

These two are minor drawbacks.
Certainly it would be nice if they could be avoided,
but given the choice I'd much rather have a warning
with these drawbacks than to not have it at all!

>  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.

Here I agree with Devang -- because Objective-C is dynamically typed
for these, they are fundamentally different from functions, variables,
etc., and the difference may justify a different approach.

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

I don't think that is particularly important.  I doubt that the cost of
this warning is likely to have that much of an affect on compilation time.
And it is after all optional.

> 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. :-)

I think you are trying to enforce a particular coding style here.
And I am not at all convinced that this coding style is always appropriate.

Many modern programming languages permit forward references
(e.g. calls to functions before they have been declared).
In general the trend has been away from languages that require
forwar declarations towards languages that allow arbitrary forward
references.  And many programmers make use of this feature.

If the @interface occurs in a header file, there may be good reasons to
leave the header file unchanged, even if you are adding a new private
method.  It's very useful to be able to change the implementation without
needing to modify the header file.  C++ doesn't allow that, and it has
been criticized for it.  (You can use local static functions instead of
private member functions, but then you have to explicitly pass in the
`this' pointer, which pretty soon starts to look ugly.)

These days programmers routinely make use of sophisticated cross-reference
tools, code browsers, etc.  So forward references are not such a big
deal for readability as they used to be.

A style check for no forward references, if it is really desirable,
is only going to be wanted by a subset of Objective-C programmers.
It should be decoupled from checking that @selectors exist.

So I would lean towards accepting the patch.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.