Re: PATCH: Selector warning

[Nicola Pero <nicola at brainstorm dot co dot uk>]

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

What happens ?  That they write horrible code ? :-)


> So, this is not just Apple specific.

Sure - but I would like to have my ObjC tidied and changed to conform to a
higher standard of quality if the compiler warns me when the code quality
seems to fall below a basic level.  Your main problem seems to avoid
changing Apple code - which I don't think is the right approach to the
problem.  Maybe the person writing the compiler warning code should not be
the same person having a lot of code to check :-) otherwise he might no
longer be impartial, but is flawed to have the compiler warnings tailored
on his own code. :-)


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

You didn't provide a way to make it to work with the GNU runtime anyway,
and I don't see any :-) unless you check when @selector() is found, so it
would have been useless for GNU users anyway - it would be an Apple OSX
with next-runtime only patch.

As such, you are not really giving us any benefits by applying the patch.
It only works on Apple OSX with the next runtime - that is, it's basically
useless unless used with your company proprietary Objective-C frameworks,
which only run on your company proprietary operating system.

Of course there might be compromises - a compromise would be to check at
the end of compilation for the next runtime, and when a @selector() is
found for the gnu runtime.  But then the semantics of -Wselector would
differ between the two runtimes, so it doesn't look like a great idea.

Maybe a better solution would be to have two different flags.  If you
don't perform your check in -Wselector (which is already used for
something else), but in a flag of your own, that might lower my
opposition, since only users explicitly adding your flag will turn your
code on, and well they get what they ask for.

If you add a flag with your code, I'd appreciate adding another similar
one for perfoming the checks in the @selector(), so that GNU runtime users
can have a flag to perform those checks, which IMHO is definitely better
too.  I'll write that code myself if needed, it's trivial.

I still see a lot of space for compromises. :-)