Re: [objc-improvements] Warnings when compiling GNUStep

[Ziemowit Laski]

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

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

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

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?

Thanks,

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