[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: Mon, 01 Sep 2003 23:41:10 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

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

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

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

where all classes implementing a "concrete"
-(NSComparisonResult)compareToXXX:(NSXXX *)o;
must implement:
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

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


reply via email to

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