On Nov 18, 2009, at 2:32 PM, Jens Alfke wrote: > On Nov 18, 2009, at 11:15 AM, Jim Correia wrote: > >> This problem is just not restricted to private methods, or additions through >> categories. You can also run afoul of a namespace conflict with a public >> method in your subclass. > > Yes; but this is less likely because Apple engineers add public methods less > often (almost never in minor updates) and more carefully.
Agreed. Subtle breakage is still possible across a major release when both you and Apple choose the obvious name for new functionality. -isHidden/-setHidden: on NSView is the sort of thing (which was added recently enough that many people likely remember it.) If you had subclassed NSView to add that functionality, its pretty likely you would have chose those names, or -isVisible/-setVisibible: because they are the obvious solution to the problem. You can avoid namespace clash altogether by writing ugly code, with names no one would ever want to use for your methods and properties. But who wants to do that? :-) Jim_______________________________________________ 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 arch...@mail-archive.com
