|
From: | David Ayers |
Subject: | Re: [objc-improvements] RFC: Message passing prototype search cleanup |
Date: | Sat, 06 Sep 2003 12:05:50 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |