Re: [objc-improvements] Warnings when compiling GNUStep

[Ziemowit Laski]

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