This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Selector warning
- From: Devang Patel <dpatel at apple dot com>
- To: Nicola Pero <nicola at brainstorm dot co dot uk>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 5 Aug 2002 11:00:09 -0700
- Subject: Re: PATCH: Selector warning
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