[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 16:54:53 -0700

On Thursday, Sep 4, 2003, at 16:33 US/Pacific, Alexander Malmberg wrote:

Ziemowit Laski wrote:
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
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.

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

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
@interface Foo (category1)
-(NSArray *) foo: (float)f;
@interface Foo (category2)
-(NSMutableArray *) foo: (float)f;

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

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
implementation of the prototype search, is the best one.

Since the runtime will pick the derived-most method to dispatch to, I'm
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?


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]