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

[Ziemowit Laski <zlaski at apple dot com>]

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

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

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

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

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