On Jan 29, 2014, at 4:44 PM, Graham Cox <graham....@bigpond.com> wrote:
> > On 30 Jan 2014, at 8:03 am, Keary Suska <cocoa-...@esoteritech.com> wrote: > >> Absolutely, and I have found it invaluable to troubleshoot state issues, but >> unfortunately it is not App Store safe (read: basis for rejection), as it >> relies on a private method call for proper NSDocument change tracking... > > > It does? > > I'm using it in an App Store app without it ever having come up as an issue. > Have you actually had this flagged as an issue by The Keepers Of The Store™? > > If you're referring to: > > - (void) _processEndOfEventNotification:(NSNotification*) note > > > I'm not sure that counts as using private API as such. It's just a stub for a > method that NSDocument calls on its undo manager, and as you can see it's > only a notification handler (containing no code). It's needed because > NSDocument doesn't check whether the undo manager implements it before > calling it, so it will cause an unrecognised selector exception if it's not > there, but it's not actually calling any private API itself anywhere - > NSDocument is. It doesn't matter if you are calling it, or if the framework is calling it - you are effectively "using" the private API. Method names with leading underscores are defined as private methods, reserved for Apple. From <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html#//apple_ref/doc/uid/20001282-1003829-BCIBDJCA> (emphasis mine) Private Methods In most cases, private method names generally follow the same rules as public method names. However, a common convention is to give private methods a prefix so it is easy to distinguish them from public methods. Even with this convention, the names given to private methods can cause a peculiar type of problem. When you design a subclass of a Cocoa framework class, you cannot know if your private methods unintentionally override private framework methods that are identically named. Names of most private methods in the Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark them as private. From this fact follow two recommendations. • Don’t use the underscore character as a prefix for your private methods. Apple reserves this convention. (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 - in the mean time, file a bug asking that NSUndoManager can be fully replaceable with publicly declared methods only). _______________________________________________ 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
