[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

David Ayers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]