Re: New warnings (hopefully) in gcc 3.4

[David Ayers]

Alexander Malmberg wrote:

> David Ayers wrote:
> [snip]
>  
>
> > and we always declare
> > -(NSComparisonResult)compare:(id)o;
> >
> > where all classes implementing a "concrete"
> > -(NSComparisonResult)compareToXXX:(NSXXX *)o;
> > must implement:
> > -(NSComparisonResult)compare:(id)o;
> > 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: ]
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/gdl2/EOControl/EOSortOrdering.m?rev=1.10&sortby=date&content-type=text/vnd.viewcvs-markup

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
> > -(NSComparisonResult)compare:(NSXXX)o;
> >
> > 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.

Cheers,
David

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:

http://mail.gnu.org/archive/html/discuss-gnustep/