[Top][All Lists]

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

Re: [objc-improvements] Merging back to mainline

From: Steve Naroff
Subject: Re: [objc-improvements] Merging back to mainline
Date: Fri, 5 Sep 2003 15:28:05 -0700


What is the disagreement about the handling of conflicting method signatures?

As you know, this is only a problem when using anonymous types (i.e. "id"). Since using anonymous types with multiple method signatures is ambiguous, the only thing the compiler can do is pick one (the first one it encounters is as good as any), warn, and make it clear which version was chosen.

[steve-naroffs-Computer:~] snaroff% cc -c xx.m
xx.m: In function `main':
xx.m:20: warning: multiple declarations for method `bar'
xx.m:6: warning: using `-(void)bar'
xx.m:12: warning: also found `-(float)bar'

It has worked this way ever since 1988 when I implemented it. I have never heard of any controversy or problem until recently. The obvious way for programmers to remove the ambiguity is to declare the class or protocol so the compiler can know what it is doing.

Please advise,


On Friday, September 5, 2003, at 02:53 PM, Ziemowit Laski wrote:

Hello all,

As our work on the objc-improvements-branch progressed (with the
great help of several GNUSteppers -- you know who you are), various
ideas for altering/improving the behavior of the ObjC front-end
have emerged.  While there is still some disagreement as to some
of these (most notably the handling of conflicting method signatures),
they are definitely important issues that we will need to work on
further and resolve.

Having said that, though, I also believe that it is time that we
separate concerns whenever possible.  Since it is difficult to tell
how long it would take us to resolve the issues we discovered, and/or
whether we will discover still other issues along the way, I think
that we should merge what we already have back to the mainline as
soon as possible.

The question that I have is therefore the following: Does the
objc-improvements-branch, in its present shape, fail to build GNUStep
or any associated apps or, if they do build, has their behavior
changed in some erroneous way?  If the answer is yes, then we
should definitely fix any remaining bugs before moving forward.
But if the answer is no, I think we should go for the mainline merge.
We really can't put this off any longer if we hope to get this stuff
into the 3.4 release.  Once the objc-improvements-branch fixes have
made it into the mainline, we can continue addressing the remaining

The other two motivating factors here are:
  (1) I'd like to re-use the objc-improvements-branch for
      FSF Objective-C++ work, as I'd really hate to juggle two
      branches simultaneously if I can avoid it.
  (2) I won't have time to work on FSF issues forever. :-(  There is
      currently a window in Apple's schedule that I'm exploiting, but
      it won't remain open for long. :-(

Thanks for your understanding, and I look forward to your feedback.

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]