This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Your 'Class <Protocol>' Work


On 12 Oct 2004, at 9.37, David Ayers wrote:

Ziemowit Laski wrote:

I say "some" because the compiler will still warn that "no `+foo'
method found" in some situations where you probably think it
shouldn't (see class-protocol-1.m). The reason that I left things in
this state is that I'd like to attack these superfluous messages with
a separate patch that enhances how protocols get used for message
lookup. Because these enhancements will affect cases other than just
'Class <Protocol>', they deserve a separate e-mail thread and
discussion, which I will start forthwith.

This is not an issue of "superfluous messages", it is a code gen issue.
All other cases where the instance methods of root classes are
concerned already handle this correctly. I fail to see why this needs
to be separated from the patch, in fact I find the patch incomplete (if
not broken) if it fails to handle these cases. By "handle" I mean using
the correct prototype.

With my most recent patch, messaging 'Class <ProtoList>' will first search
for a class method in ProtoList, then for an instance method in ProtoList,
and finally perform an unadorned 'Class' lookup. If neither a class nor
an instance method is found in ProtoList, then I think the 'Class' (or,
similarly, 'id') lookup _should_ look in the hash table, at which point
no prototype chosen is any more "correct" than any other in the hash table.
Of course, if multiple prototypes are found, the compiler will warn and
tell you which one it is using.


I do expect the
compiler to use the prototype of the instance methods of those
protocols.

It does that.


  At least for protocols which are adopted by root classes, as
I'd compromise not to mark protocols and always use the instance
prototypes.  --- OK.  I'm going in circles.  Please let me know if I
haven't made myself clear yet and I'll try again.  But I think you
simply seem to be ignoring the importance of this issue looking at it
like a "nice to have".  I strongly disagree.

I must say that I strongly disagree with the notion of "root protocols". :-(
Under that scheme, if a class method lookup in ProtoList (for a 'Class <ProtoList>'
receiver), then we look for instance methods in ProtoList, but only for those
protocols that were adopted by some root class, right? So, at the message send
site, the user will have to remember which protocols have been adopted (directly
or indirectly!) by root classes and which have not in order to understand how
the compiler will select that particular method signature. I find such
lack of determinism (at least from the end-user's viewpoint) objectionable.


Furthermore, I thought that you agreed that it was an acceptable compromise
to look at instance methods in all protocols in ProtoList (and warn appropriately)
if a class method is not found, which is what my current patch does. Why is
it that you now find this objectionable?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]