[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 14:24:36 -0700 |
On Thursday, Sep 4, 2003, at 12:20 US/Pacific, Alexander Malmberg wrote:
Ziemowit Laski wrote:
On Wednesday, Sep 3, 2003, at 17:35 US/Pacific, Alexander Malmberg
wrote:
Ziemowit Laski wrote:
On Wednesday, Sep 3, 2003, at 13:37 US/Pacific, Dirk Theisen wrote:
Covariant return types. Those are absolutely valid and I think you
know that. If not, I can dig up the relevant (oldish) papers. This
would give ObjC a little bit more expressive power in some cases
and
another advantage over Java.
Covariant return types (unlike covariant arguments :-) ) are valid
in
an OO-theoretic sense,
Why not arguments? As far as I can tell, this applies to arguments as
well, but the "other way". Ie. for return types a subclass can
specify
a
more specific type, while for arguments, a subclass can specify a
more
generic type.
...which would make them contravariant, not covariant. :-)
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. :-)
[snip]
You can declare that today, without prejudice (or warnings).
But only because the compiler doesn't check prototypes properly. My
patch fixes that, and it would (definitely correctly) find both
prototypes, and (not necessarily correctly in this case) issue a
warning.
Personally, I like this idea, but it has been shot down within Apple.
I suppose you can enable it only if !flag_next_runtime.
A warning option (-Wno-conflicting-prototypes?) for this would be ok
since it doesn't affect behavior (you wouldn't get the warning, but
you'd still get the same "random" prototype). If you really think it's
necessary, we could make that the default for -fnext-runtime;
otherwise,
you (or others who don't want the warning) would simply use that option
when compiling.
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'.
[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...
In particular, it doesn't completely match what the runtime would do
wrt. categories. At runtime, categories override the main interface,
but
in gcc, the main interface is searched before the categories and thus
overrides them.
Yes, but how do you know that the categories are not loaded in later
via a shared
library? Also, do you know which categories actually get loaded, and
in what order? I guess
if you want to make the multiple prototype checking more robust, you
could consult any
visible categories for conflicts and report them; but, you'll still
need to _use_ the
prototype in the main interface, IMO.
--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, Alexander Malmberg, 2003/09/03
- 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 <=
- 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, Nicola Pero, 2003/09/05