[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [objc-improvements] Warnings when compiling GNUStep
From: |
Ziemowit Laski |
Subject: |
Re: [objc-improvements] Warnings when compiling GNUStep |
Date: |
Thu, 4 Sep 2003 16:54:53 -0700 |
On Thursday, Sep 4, 2003, at 16:33 US/Pacific, Alexander Malmberg wrote:
Ziemowit Laski wrote:
[snip]
OK, I'll rephrase it: If we were to add handling of covariant return
types, is there any reason why we wouldn't want to add handling of
contravariant argument types?
I'm not entirely sure what "handling" would mean in this case (since
covariant
return types are already allowed, among other things), but I suspect
this too
would have to live behind a flag so that Apple may disable it. :-)
It would affect the warnings when not using
-Wno-conflicting-prototypes.
[snip]
Thing is, when checking either typed receivers and/or protocols, you
should not
get a "random" signature; you should get the first method that is
found
(you
first look in the type, and failing that, you examine each protocol in
turn). The
"randomness" (if we want it at all -- I still don't quite understand
why people
insist on it...) should only kick in when we're sending to 'id' or
'Class'.
If we documented the search order and guaranteed to keep the search
order that way, that would remove a lot of the "randomness". We still
have categories, though:
@interface Foo
@end
@interface Foo (category1)
-(NSArray *) foo: (float)f;
@end
@interface Foo (category2)
-(NSMutableArray *) foo: (float)f;
@end
You can pick randomly, fall back to the default prototype (not
acceptable), or try some merging magic (not pretty).
I believe the current approach will find 'foo' in category1 and stop
there.
Of course, if the main interface had a 'foo', that would be our choice.
Of
course, if -Wconflicting-prototypes is specified, you're still free to
warn
about all the other foo's...
[snip]
But when you have a receiver type to work with (i.e., it is _not_ an
'id' or
'Class'), then you simply pick the closest ("derived-most")
If you want people to rely on rules for getting the "derived-most"
prototype, I suggest that we define these rules properly and document
them. It isn't clear that the current "rules", implicitly defined by
the
implementation of the prototype search, is the best one.
Since the runtime will pick the derived-most method to dispatch to,
I'm
not
sure why you object to this. Most object-oriented languages do
this...
That's probably because those languages are pretty static. As you point
out below, we don't know whether categories will be loaded or not, or
in
which order. IOW, there is no static "derived-most" order that we can
check prototypes in. If we want a defined order, the best we can do is
pick an order that does the right thing as often as possible, and
document it.
In general, the existence of categories (along with a possibility of
them being loaded at runtime)
can alter any and every method lookup at runtime, which may lead us to
conclude that none of the
method signature selection approaches we've discussed are any good. :-)
However, I believe it
is OK to accept the fact that the compiler has a more static view of
the world than the runtime
will. And so, when the type of receiver is known, we start with its
class and work our way up
the class hierarchy. For each class in the hierarchy, we first check
in the main interface and
then in any visible categories, in the order that they are declared in
the sources. Yes, at
runtime things can get rearranged in a different order, but we can't
possibly know that, and so
we shouldn't care. :-) :-)
Anyway, can you (Alex) commit your patch so that we can all play around
with it? We can always
change/revert it later. Or, if you do not have write access, can you
_attach_ it as a diff
that I could 'patch' in?
Thanks,
--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
- Re: [objc-improvements] Warnings when compiling GNUStep, (continued)
- Re: [objc-improvements] Warnings when compiling GNUStep, Nat!, 2003/09/03
- Re: [objc-improvements] Warnings when compiling GNUStep, Kai Henningsen, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Ziemowit Laski, 2003/09/03
- Re: [objc-improvements] Warnings when compiling GNUStep, Alexander Malmberg, 2003/09/03
- Re: [objc-improvements] Warnings when compiling GNUStep, Ziemowit Laski, 2003/09/03
- Re: [objc-improvements] Warnings when compiling GNUStep, Riccardo Mottola, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Alexander Malmberg, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Ziemowit Laski, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Alexander Malmberg, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep,
Ziemowit Laski <=
- Re: [objc-improvements] Warnings when compiling GNUStep, Nicola Pero, 2003/09/05