On 31 Jan 2014, at 2:39 am, glenn andreas <gandr...@me.com> wrote: > One work around would be to implement "doesNotRecognizeSelector:" and ignore > it there, and this would also make it future safe for when new private > methods are added
That sounded like a better solution. However, the documentation states: "If you override this method, you must call super or raise an NSInvalidArgumentException exception at the end of your implementation. In other words, this method must not return normally; it must always result in an exception being thrown." So, cavalierly ignoring that advice, I swallow that one selector by doing nothing, and sure enough, NSDocument crashes. If I throw the exception as advised, it does not gain me anything. So right now, the "private" stub is the only solution unless, as you say, Apple allow genuine substitution of the class based solely on public API. That's not going to help for existing OS (nor for the foreseeable future, as I can imagine Apple are not going to move on this anytime soon, if ever). I will file a radar however. --Graham _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
