Re: New warnings (hopefully) in gcc 3.4

[David Ayers]

Alexander Malmberg wrote:

> In particular, the -compare: conflict is serious. NSObject has:
>
> -(NSComparisonResult) compare: (id)o;
>
> , ie. -compare: can be used to compare an object to some other arbitrary
> object. -compare: is used that way by the library in some places.
> Several other classes have:
>
> -(NSComparisonResult) compare: (NSString/NSDate/NSNumber *)o;
>
> , ie. -compare: can only be used to compare against certain specific
> types.
>
> Either the compare:(id) in NSObject, or the non-id compares need to be
> changed to id (and their implementations updated). I've attached a test
> case that raises an exception due to this issue. Which one should we
> keep?
Thinking about this about reveals that we may want to change/augment the 
API a bit and that we even have a conceptual precedance.  I'd suggest 
that the "concrete" comparisons are moved to new methods called:
-(NSComparisonResult)compareToString:(NSString *)o;
-(NSComparisonResult)compareToDate:(NSDate *)o;
-(NSComparisonResult)compareToNumber:(NSNumber *)o;
....

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)

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.

Cheers,
David