[Top][All Lists]

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

Re: New warnings (hopefully) in gcc 3.4

From: David Ayers
Subject: Re: New warnings (hopefully) in gcc 3.4
Date: Wed, 03 Sep 2003 10:27:16 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Alexander Malmberg wrote:

David Ayers wrote:
and we always declare

where all classes implementing a "concrete"
-(NSComparisonResult)compareToXXX:(NSXXX *)o;
must implement:
to call the corresponding:
-(NSComparisonResult)compareToXXX:(NSXXX *)o;
(with an applicable cast)

A cast isn't enough. It needs to check that the other object is of the
correct class (or at least some compatible class) and fall back to some
other comparison if it isn't. Object address, like NSObject? Compare
class names?

Actually a cast wasn't necessary, but you are right, the underlaying problem are the semantics of -compare: itself.

First of all, the "culprit" declaration/implementation is NSObject's -compare:. Yesterday, when we talking on about this, I was sure it had to do with EOKVC. But I was wrong. It's needed GDL2's EOSortOrdering implementation which introduces variations of -compare: (-compareAscending: -compareDescending:) based on -compare: and it is an NSObject category: [insert link to WO 4.5 documentation here, which seems to have been removed permanently from Apple's site :-/, so you'll have to take my word on it and look at: ]

After GDL2 was integrated into our repository many of the NSObject categories were moved to additions. Now I think the implementation of -compare: in NSObject should definatly be removed. But the declaration will have to remain, but not necessarily here. We could hide in EOSortOrdering.m in which case I believe the compiler warnings would probably disappearand the id-return-type-assumption would disappear

Yet none the less, the usage of -compare: is a very delicate subject as you're example displays. The current inplementation is compatible with OPENSTEP and Cocoa though (i.e. it breaks in pretty much the same why given your example.). The problem is, there is no simple test to see if -compare:ing two objects is safe unless you allready know they are both NSString, NSDate or NSNumber instances. Will have to ponder a bit more about how to solve this. Currently I'm leaning towards changing our semantics of -compare: to allow comparison of different classes, like you suggest. One way would be to compare the objects descriptions or thier class names (only when the classes don't match of course). Both aren't really meaningful, especially given that all three of the "well known" classes are actually class clusters with a plethora of class names.

The precedance to this is isEqual(ToXXX):.  Yet as Apple's API does not
implement these, we need to implement the:
-(NSComparisonResult)compareToXXX:(NSXXX *)o;
in GSCompatibility.m
to call

If I can get some yea's on this, I can prepare a patch.

I think it looks good, although the -compareToXXX: may be overkill
unless someone really needs the extra performance it gives.

Actually the issue wasn't performance but type checking. I had meant to change all -compare: signatures to:
- (NSComparisonResult)compare:(id)other
in all cases and introduce
- (NSComparisonResult)compareToXXX: (NSXXX *)other
to allow better compile time type checking possibilities.
But if we remove NSObject's declaration from the public header it might not be necessary to introduce these. Yet it would mean that id typed receivers would still see the warnings and the compiler would be wrong about the id-return-type-assumption, which is a more serious issue, but I think you're already working on that.


PS: I've kept you as a reciever of the mail as -discuss is currently exceedingly slow. PPS: I've also cc'ed Zem, so that he can follow the issue. This is the reason we should definatly introduce an ObjC specific GCC list.

Zem, our archives are located at:


reply via email to

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