PATCH: Selector warning

[Devang Patel]

It's OK to disagree.

On Monday, August 5, 2002, at 01:56  AM, Nicola Pero wrote:

>
> According to the language standard, of course you can declare any
> @selector() you want, and the compiler should silently compile it 
> without
> any warning - it can always compile it and if the programmer knows what
> she's doing, the @selector() might be perfectly well-defined at runtime
> (maybe from a third-party library or loadable object which will be
> available at runtime) even if there is no way the compiler can know 
> about
> it at compile time.  Of course, it might as well be not defined 
> anywhere
> and cause troubles at runtime - the programmer is responsible for it.

This is the unique situation, I am talking about. You can't say same 
thing
about functions.

>> This is a unique situation.
>
> It's not.
>
> The compiler is just matching the use of something (a selector) with a
> corresponding declaration.  This is done in zillions of other cases in
> languages of the C family.  And the compiler never, as far as my user
> experience has been, 'looks ahead' for declarations.  You must declare
> stuff before you use it.


> You might have millions of valid selectors at runtime, which are not 
> known
> at compile-time by the compiler.  In the same way as you might have
> millions of functions valid at runtime, which are not known at
> compile-time by the compiler.

This explains why selectors are different from normal C functions
as far as compile-time issues are concerned and so I disagree with
your following conclusion.

> This is exactly the same as for functions or methods - if the function 
> or
> method is declared or implemented before it's used, the compiler can
> easily check that what you want to use exists, and should generate no
> warning.


> Now you are proposing to introduce an ugly hack to prevent code from 
> Apple
> from generating the warnings it should generate -

IMO, it is not just Apple code. Most of the Objective-C programmers 
know that
they are not forced to provide method declaration in @interfaces. And 
when
programmers are not forced, we know what happens. So, this is not just 
Apple
specific.

> you are suggesting that
> if a selector is implemented *after* it is used, the compiler 
> generates no
> warning.  This is *exactly* that same as saying that if a function is
> implemented after it's used, the compiler should generate no warning.
> Checking the list of selectors only at the end of compilation is 
> exactly
> like checking that functions exist at the end of compilation rather 
> than
> when they are found.

It is illegal to use function, whose signature is not provided during 
compile-time.
However same is not true for selectors.  That's why compiler is not 
giving
warning until now. But, now if we are trying to help user we must wait
until end of compilation.

>  * your code is not only checking the @selector() declarations (which 
> are
> very few), but it is checking the whole list of selectors defined in 
> the
> code, both from @selector() and from method calls (which are a lot more
> than the @selector()s, normally two or three order of magnitudes more) 
> -
> which is wasteful - for each of them you then compare it with the whole
> list of method names declared in code (which might be a lot if you 
> include
> big system headers) - this might not be a practical issue on modern 
> super
> fast cpus, but it still gives me the impression you are wasting cpu 
> cycles
> for nothing

It is expensive, but relatively cheap if due to one typo error, one 
selector
goes unnoticed and results in run-time failure which will be very 
expensive
to track down. And this is not ON by default. User explicitly wants it 
so
he/she is ready to pay extra cycles.


> And if Apple has code which would generate warnings in this case, they 
> are
> well deserved and I think Apple source code would just be made better 
> by
> the very little tidyups required to remove the warnings.

Once again, I totally disagree with the definition of what is 'better 
code'.
Certainly the language designers and implementors did not enforced this
restriction (-- must need decl in @interface), so not following one 
practice
does not mean the code is not good.

It seems that we have reached at a point were it is hard to agree.
So unless somebody else steps in, I will revoke my patch. It will stay 
as
one of many rejected patches in our local sources.

-Devang