[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[objc-improvements] Warnings when compiling GNUStep
From: |
Ziemowit Laski |
Subject: |
[objc-improvements] Warnings when compiling GNUStep |
Date: |
Tue, 2 Sep 2003 17:17:26 -0700 |
The objc-improvements-branch compiler can now successfully churn its
way through the GNUstep compile-all script, although it does produce
some new warning messages along the way, and I wanted to solicit your
opinion as to what (if anything) to do about it.
First and foremost, we have numerous instances of the following:
GSObjCRuntime.m: In function `GSAutoreleasedBuffer':
GSObjCRuntime.m:1497: warning: `Class' may not respond to
`+methodForSelector:'
GSObjCRuntime.m:1497: warning: (Messages without a matching method
signature
GSObjCRuntime.m:1497: warning: will be assumed to return `id' and
accept
GSObjCRuntime.m:1497: warning: `...' as arguments.)
GSObjCRuntime.m:1497: warning: assignment from incompatible pointer
type
(The "incompatible pointer type" warning is a direct consequence of not
finding
a suitable method in the first place.) There does exist an instance
`-methodForSelector:'
in the 'NSObject' class (which probably gets used in this case), but
since Objective-C
allows multiple root classes, the compiler cannot statically decide to
focus on NSObject.
What should we do? I see 3 choices:
(1) Leave things as they are. Users will be able to suppress the
above warning by
casting the receiver to the root class (in above case, '(NSObject
*)').
(2) Build a list of all plausible root classes (i.e., classes without
superclasses),
and consult all instance methods for those classes when
dispatching messages to
'Class'
(3) Treat messages to 'Class' the same way we treat messages to 'id',
i.e., consult
all class and instance methods available. This is what the
compiler appears to
have done until now (in its mercurial and buggy way).
Personally, I like types (and compiler's warnings about them) :-), so
I'd advocate we stick
with (1), but we could also do (3). I'd really, really hate to have to
implement (2), however.
Not only is it extra work, but it will adversely affect compile time.
Then, we have things like
GSCompatibility.m:696: warning: multiple methods named
`-objectForKey:' found
GSFileHandle.m:1245: warning: multiple methods named `-objectForKey:'
found
GSFileHandle.m:1294: warning: multiple methods named `-objectForKey:'
found
NSUserDefaults.m:791: warning: multiple methods named
`-initWithPath:' found
:
where we're sending messages to receivers of type 'id'. In the
majority of cases,
the compiler is absolutely right to complain, and the receiver should
be cast to a more
specific type (and/or the corresponding method signatures should be
cleaned up so that
they match up). However, in a few cases we're dealing with the idiom
[[ClassName alloc] init...]
in which case one _could_ make the argument that any method named
'alloc' should be treated
specially by the compiler, i.e., as having a return type covariant with
the receiver. What
do you think? If we don't teach the compiler about 'alloc', then it is
perfectly within
its right to complain in this case also, unless we change foregoing to
read
[(ClassName *)[ClassName alloc] init...]
which, I must admit, does have a slighty redundant flavor to it. :-(
Of course, the
slippery slope argument applies here (if we treat 'alloc' specially,
then what about
'allocWithFoo:Bar:'?...)
Finally, we have
GSXML.m:3765: warning: `GSXPathObject' may not respond to
`+_newWithNativePointer:context:'
NSDistantObject.m:110: warning: `GSDistantObjectPlaceHolder' may not
respond to `+class'
NSTimeZone.m:685: warning: `NSTimeZone' may not respond to
`+arrayWithObject:'
:
all of which do seem reasonable to me, but please double-check.
Other than that, things look pretty good! Please take the
objc-improvements-branch compiler for a
spin one more time. I'd like to get this pushed into mainline 3.4 as
soon as feasible, so that I
may embark on phase 2 of my project -- Objective-C++! :-)
--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477
- [objc-improvements] Warnings when compiling GNUStep,
Ziemowit Laski <=