FROM : Jens Alfke
DATE : Tue Apr 22 18:09:51 2008
On 22 Apr '08, at 8:19 AM, Dave Camp wrote:
> The problem is that I get the warning "initialization from distinct
> Objective-C type" when I do this, because the NSNumber class methods
> return a specific type instead of id.
It's safe; you'll just need to cast the return value to
(NSDecimalNumber*) to avoid the warning.
I'm not sure I'd call this a bug in the headers. Most statically-typed
OOP language have this kind of problem handling methods that are
overridden to return a subclass instance. They could change the return
type to "id", as other classes like NSDictionary do, but then you lose
the type-checking. (There are several times I've accidentally assigned
[NSMutableArray array] to an NSSet*, for example, and wasted time
tracking down weird exceptions at runtime.)
—Jens
DATE : Tue Apr 22 18:09:51 2008
On 22 Apr '08, at 8:19 AM, Dave Camp wrote:
> The problem is that I get the warning "initialization from distinct
> Objective-C type" when I do this, because the NSNumber class methods
> return a specific type instead of id.
It's safe; you'll just need to cast the return value to
(NSDecimalNumber*) to avoid the warning.
I'm not sure I'd call this a bug in the headers. Most statically-typed
OOP language have this kind of problem handling methods that are
overridden to return a subclass instance. They could change the return
type to "id", as other classes like NSDictionary do, but then you lose
the type-checking. (There are several times I've accidentally assigned
[NSMutableArray array] to an NSSet*, for example, and wasted time
tracking down weird exceptions at runtime.)
—Jens
| Related mails | Author | Date |
|---|---|---|
| Dave Camp | Apr 22, 17:19 | |
| Jens Alfke | Apr 22, 18:09 |






Cocoa mail archive

