[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: Ziemowit Laski
Subject: Re: [objc-improvements] RFC: Message passing prototype search cleanup
Date: Thu, 4 Sep 2003 17:47:52 -0700

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

Ziemowit Laski wrote:
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
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

Yes, exactly.  Depending on the flag setting, you either bail out or
continue searching (for duplicates).

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

I suspect it's a bit of both, and the problem is as much political as it
is technical  -- i.e., it is quite difficult to get people to change
their sources. :-)  This, combined with the fact that many projects
use -Werror for their builds, means that any new warnings could cause
new build failures.

* 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'"

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.

Yes, I think you're right.

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

1. Interface of the class.
for each category (in a "random" order):

Is is really "random"/"pseudo-random" here?

  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.

Plus, at each step 1-6, if we're looking for a class method, did not find it
and the interface we're working with does not have a superclass, then
look for an instance method as a last resort (this also applies to
any protocols attached to the interface.

7. Protocols specified in the type (recursively, depth first).

Before fixating this, I suggest that we move 4. up right below 1.

Yes, I agree with you here.
consistency. Also, we might want to consider checking categories before
we check the main interface, since this is what the runtime will do.

I suppose we could assume that if the user included a category declaration in a translation unit (as opposed to placing it in a different translation unit), then he/she intends that category to be used, so I agree as well, at least in principle. How well Apple sources will withstand
such a change is another question altogether. :-)

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.

Of course, under your scenario, casting the receiver will do you no good, since you could _still_
find multiple method signatures, right? :-)

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

reply via email to

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