[Top][All Lists]

[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
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
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. :-)

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

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

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]