Re: [objc-improvements] RFC: Message passing prototype search cleanup

[Alexander Malmberg <alexander at malmberg dot org>]

Ziemowit Laski wrote:
[snip]
> > If more than one prototype is found, one of them will be picked
> > "randomly" (in practice, the search is done in a specific order, so it
> > isn't really random; I don't think we want users to rely on that,
> > though). This is ugly from some povs, but it's compatible with previous
> > versions of gcc, and it does the right thing in most cases (when there
> > are slight prototype mismatches).
> 
> If you can find a way to conditionalize this behavior (e.g., on
> '-Wcheck-conflicting-prototypes'
> or some such), that's great.  A flag will be needed, though, because
> Apple will most likely
> turn it off by default. :-(

A flag is no problem. I'll even have it return early when it finds a
prototype, which should remove any performance hit the warning might
have.

Out of curiosity, is this an issue with apple's own source, or with the
headers, and thus all source using your libraries?

[snip]
> > * If a message is sent to a receiver with a type we have not seen an
> > interface for, a warning is issued:
> >
> > "no interface seen for `SomeClass'"
[snip]
> 
> Our resident NeXT-ies hate it when the ObjC compiler throws new
> warnings at them,
> but in this particular case I think that they will see the light. :-)

At worst, I could add an option to disable it. However, in (I think) all
cases, the compiler will issue a warning anyway ('may not respond to' or
'no prototype found' or something), so this extra warning is just making
the cause of those warnings more obvious to the developer.

> > +
> > +  /* Search for a suitable prototype. If we can't find one, we use our
> > +     fallback prototype: id (*)(id,SEL,...).
> > +
> > +     First we check if the type information known for the receiver
> > gives any
> > +     prototypes. If this gives us a unique prototype, we use it. If
> > it gives
> > +     several prototypes, we warn and use one of them "randomly" (we
> > use the
> > +     first one we find, so it's actually well defined; however, we
> > don't
> > +     want users to rely on this).
> 
> Before we started messing with things, the compiler would actually pick
> the _last_ prototype
> seen, since it simply reached into the appropriate bucket in the hash
> table (and we prepend
> things to buckets rather than appending them).  Has this been changed?

This comment applies when searching for a prototype for a known receiver
type. In that case, we used, and still use, the first prototype found in
the sortof "derived-most" search that lookup_method_static() et al do.

Currently, I consider this order to be somewhat implementation defined,
but if we wanted to, we could document it and fixate it so that users
may safely rely on it.

This would give users a nice set of options. Those who want warnings
about conflicts and don't want to worry about the search order can
enable the warning, and those who don't want warnings can disable the
warnings and safely rely on a defined search order.

For reference, the search order (both before and after my patch) is:

1. Interface of the class.
for each category (in a "random" order):
  2. The interface of that category.
  3. The protocols (recursively, depth first) of that category.
4. The protocols (recursively, depth first) of the main interface.
5. (1) through (4) for each superclass.
6. The local @implementation.
7. Protocols specified in the type (recursively, depth first).

Before fixating this, I suggest that we move 4. up right below 1. for
consistency. Also, we might want to consider checking categories before
we check the main interface, since this is what the runtime will do.

> > +       warning ("(When multiple prototypes are found for a receiver type,
> > one");
> > +       warning ("of them will be picked randomly (but
> > deterministically).)");
> 
> You know, this message is probably more confusing than any of the
> previous candidates. :-) :-)
> At this point, I'm really inclined to say that we should go back to the
> original warning
> behavior: We found multiple signatures, we'll be _using_ such-and-such,
> although we also found
> this, this and that. :-)

The warning will say which one it will use. I guess this makes the
extended warning a bit redundant.

> At the end of that diatribe, we could perhaps
> issue a one-time warning
> that the user may want to cast the message receiver to the desired type
> to avoid all the madness.
> What do you think?

For the "untyped" search, this could be a good idea. The wording will
probably depend on which behavior we'll have in that case, though.

- Alexander Malmberg