This is the mail archive of the 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 5 Oct 2004, at 9.34, David Ayers wrote:
>> Ziemowit Laski wrote:
>>> Took me longer than expected, but here is the alternative patch I
>>> promised; no ChangeLog entries for now.  It's running a bit late, so
>>> I'll defer my commentary until tomorrow. :-(  As always, feedback is
>>> welcome.
>> Hello Zem,
>> well I guess we have different views on a gratuitous rewriting of
>> objc_comptypes :-), but your version seems fine.
> Good to hear it. :-)

Actually I have to take that back.  I just tried to have a closer look so
that I could integrate this part into my version but it seems that your
handling is incomplete.  It get's gets the:

id <proto> =/== Class <proto>

case wrong.  I have to admit that the test case was missing for that
variant (and maybe some others).  I'll try to come up with a more complete
comptypes tests.  But for now simply add:

  clsP1 == objP1; /* { dg-warning "lacks a cast" } */
  objP1 == clsP1; /* { dg-warning "lacks a cast" } */

  clsP1 = objP1; /* { dg-warning "incompatible" } */
  objP1 = clsP1; /* { dg-warning "incompatible" } */

> I could have sworn this worked for me, but I'll check again (and also
> incorporate all of the comments you had below).
>> You seem to have omitted the part which is /very/ important to me.
>> Please! search for instance prototypes in protocol qualified Class
>> references!  What is your issue with this feature?  It is very
>> important
>> in my view wrt generating the right code.  I do not understand what is
>> bothering you about it.  I can live with doing it independent of
>> whether
>> the protocol is adopted by the root class.  But please do it for those
>> that are.
> My patch was only a work in progress (hence no ChangeLogs yet), but yes,
> the protocols in question should be searched for a matching instance
> prototype as a fallback, and if one is found, a suitable warning should
> be issued.  If that yields no result either, then we give the "not
> implemented
> by protocol(s)" warning and do the unadorned 'Class' search (which will
> give
> us instance methods implemented by root classes).  I will do this in the
> next rev of my patch; please stay tuned.

I would really suggest you work from my last patch and strip what ever you
deem necessary.  We can take a closer look at getting objc_comptypes more
compact and nuking objc_comptypes_proto_proto after the branch.

> Note also that my patch intentionally skirts the various
> cleanup/renaming issues
> we've discussed; we can do those later separately.  I also realized


> that my
> suggestion for renaming 'reflexive' to 'symmetric' is wrong :-(; a
> symmetric
> operation is one for which ((A op B) && (B op A)), whereas
> objc_comptypes()
> is really implementing ((A op B) || (B op A)).  We really should rewrite
> objc_comptypes() at some point so that it behaves more like C/C++
> comptypes().

I was wondering about that also, but the naming is tangantial so I'm not
worried about it.  I am worried about code generation (using the correct

David Ayers

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