If you have a property "value" in your subclass (using the term 'property' loosely, not in the Objective-C 2.0 sense), and Apple adds the property "value" to the superclass, you're probably going to be hosed in one way or another. For example, if Apple adds the _value ivar, they're also likely to add -value and -setValue: methods, in which case relying on KVC to find your ivar is going to fail when it finds Apple's accessors. You could avoid that by implementing your own accessors, but then Apple's code might contain calls to those accessors that expect to find Apple's implementation (or a superclass- aware subclass implementation) rather than your own superclass- ignorant implementation.

Such are the hazards of subclassing, I think.

-Jeff


On Jul 10, 2008, at 11:19 AM, glenn andreas wrote:

The problem is that while when you recompile you'll see the conflict, for existing users (who won't be compiling from source), if they use KVC they'll have the problem.

@interface NSFoo {
        id _reserved;
}
@end
@interface MyFoo: NSFoo {
        float _value;
}
@end

And OS X+1 comes out with:

@interface NSFoo {
        int _value;
}
@end

Any of your code that used _value (like, say, for bindings) could suddenly break for users of OS X N+ 1 (since they won't be compiling from source to see what is going on).


Granted, it's rare that this happens, but from time to time reserved fields do get converted to something used. And lets face it, if you hear "it works fine on OS X N, but breaks on OS X N+1", "ivar collision" isn't the first thing you'll think about to try to track down the problem...

Worse, this could actually happen on an OS X N+ 0.1 release and the headers wouldn't get updated so you won't even have the safety net of seeing compiler errors. Similarly, if you target the OS X N SDK, you won't see the new headers either.

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to