Re: [objc-improvements] Warnings when compiling GNUStep

[Alexander Malmberg]

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

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

[snip]
> 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.

- Alexander Malmberg