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

[David Ayers]

Alexander Malmberg wrote:

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

I think you're making a very important point here.  We should definitely 
match up any sequence as best as we can to the runtime behavior.  My 
current worry is that the class interface is used before the category.  
As the interface must always be included before any categories, this 
will effectively ignore any category declarations.  Yet the runtime will 
definitely use one of the category implemtations (eventhough which one 
exactly, is undefined).

So on the one hand, I would argue to move category processing before the 
interface.  On the other hand, changing the prototype in a category 
seems kind of broken anyway and haveing a rand... oops, I mean a 
'declaration order defined' selection as the primary entry point seems 
shaky.  Then again, it reflects the shakyness of the runtime behavior, 
and it's only shaky in the case of multiple categories for the same 
selector.

But let's take an example: -compare: :-) If I dislike the semantics of 
-compare: that preclude that receiver and argument must be of a similar 
class, and I implement a category which allows (id) as an argument, I 
would want the compiler to use my categories prototype rather than the 
typed prototype of the interface declaration.  I think this is a valid 
scenario of overriding the prototype (independent of the new semantics, 
which could just be raising an exception, before trying to access ivars 
of the argument to prevent segfaults).

Cheers,
David Ayers