Re: Legal Opinion on GCUndoManager
On 01 Feb 2014, at 01:02, Graham Cox wrote: > On 1 Feb 2014, at 4:32 am, Fritz Anderson wrote: >> If I were implementing the review process, my automated checker would run >> strings(1) on the binary, and flag the collision with private API. Under my >> notional process, the reviewer would have to reject, because he has no way >> of knowing how the selector is used; or, even if your use is innocent, >> whether it propagates down into the framework so the collision with private >> API happens anyway. > >> but if I’m right, the app would not simply sail through to acceptance. > > > Except that it does (so far, over several years), so the process must be > different from your notional one. > > To be on the safe side, I would prefer a cleaner way to handle this, but so > far Quincey's suggestions haven't borne fruit, though I don't properly > understand why. The problem seems clear enough: how to benignly swallow a > method invocation to a private method without actually defining the method on > the receiver. Implement one of the unhandledSelector methods and just have it return instead of erroring? But really, you’re fixing the letter of the law, not the intent: Apple’s point of prohibiting use of private API is to give them flexibility to refactor, rename and generally do unspeakable things with them without our code breaking. If Apple ever renamed that method, your interception would stop happening, and your class would break. It sounds like a safer solution would be to get Apple to either make this method public and make a promise of sorts that they’ll keep it working, or to get them to not even call it on your class (I didn't quite get the details, but I suppose they could check via respondsToSelector: before calling it?). Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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
Re: Legal Opinion on GCUndoManager
On 1 Feb 2014, at 4:32 am, Fritz Anderson wrote: > If I were implementing the review process, my automated checker would run > strings(1) on the binary, and flag the collision with private API. Under my > notional process, the reviewer would have to reject, because he has no way of > knowing how the selector is used; or, even if your use is innocent, whether > it propagates down into the framework so the collision with private API > happens anyway. > but if I’m right, the app would not simply sail through to acceptance. Except that it does (so far, over several years), so the process must be different from your notional one. To be on the safe side, I would prefer a cleaner way to handle this, but so far Quincey's suggestions haven't borne fruit, though I don't properly understand why. The problem seems clear enough: how to benignly swallow a method invocation to a private method without actually defining the method on the receiver. --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
Re: Legal Opinion on GCUndoManager
On 31 Jan 2014, at 11:46 AM, Quincey Morris wrote: > On Jan 31, 2014, at 09:32 , Fritz Anderson wrote: > >> I can’t offer legal opinions or advice (retirees from the bar are >> particularly forbidden to do so) … > > I can’t help asking: Was the retirement voluntary, or did the bar just close > at 2 am? Earlier than that. All the patrons wanted to do was fight with each other. [Off topic. No more responses to jokes, I promise.] — F ___ 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
Re: Legal Opinion on GCUndoManager
On Jan 31, 2014, at 09:32 , Fritz Anderson wrote: > I can’t offer legal opinions or advice (retirees from the bar are > particularly forbidden to do so) … I can’t help asking: Was the retirement voluntary, or did the bar just close at 2 am? ___ 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
Re: Legal Opinion on GCUndoManager
On 29 Jan 2014, at 11:24 PM, Jerry Krinock wrote: > > On 2014 Jan 29, at 13:03, Keary Suska wrote: > >> unfortunately it [GCUndoManager] is not App Store safe … as it relies on a >> private method call for proper NSDocument change tracking… > > I just spent the last half hour studying this and wrote my own concise legal > opinion arguing why GCUndoManager is OK. Now having read Graham’s post, it’s > probably redundant. But I’m posting it here anyhow in case I or anyone else > ever needs it :) > > Although -[NSUndoManager _processEndOfEventNotification:] is a non-public > API, -[GCUndoManager _processEndOfEventNotification:] is NOT a non-public > API. As a matter of fact, it is not even an Apple API! It’s the same as if > I defined a class CorePerformer and innocently named a method -[CorePerformer > _corePerformAction]. There also happens to be an Apple non-public method > -[NSMenuItem _corePerformAction]. Certainly my definition should not result > in an app store rejection. I can’t offer legal opinions or advice (retirees from the bar are particularly forbidden to do so), but this isn’t a matter of law. Apple says explicitly that the guidelines are only that: a description of the principles that characterize a completely discretionary process. They are not rules, because there are none. Rules (binding promises) could be gamed to defeat Apple’s purpose in conducting reviews. Legalism does no good (as is so often the case in life). Apple says it will do no good. If I were implementing the review process, my automated checker would run strings(1) on the binary, and flag the collision with private API. Under my notional process, the reviewer would have to reject, because he has no way of knowing how the selector is used; or, even if your use is innocent, whether it propagates down into the framework so the collision with private API happens anyway. You could appeal, and may win — solely on the technical question — but if I’m right, the app would not simply sail through to acceptance. — F ___ 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
Re: Legal Opinion on GCUndoManager
It's not the defining but the calling. If your code calls a method with the same name as an Apple private method you, at least in the iOS store get auto rejected. I see it in the dev forums constantly. At analysis time there's no way of knowing what object the method is called on so the signature counts and the analyser looks for method calls. If Graham's own code called that method then I think he'd get a rejection, but merely defining it (and letting the framework call it) doesn't trip up the detector. Whether Apple would reject apps which define methods like that if they knew about it is unknown. > On 30 Jan, 2014, at 13:24, Jerry Krinock wrote: > > >> On 2014 Jan 29, at 13:03, Keary Suska wrote: >> >> unfortunately it [GCUndoManager] is not App Store safe … as it relies on a >> private method call for proper NSDocument change tracking… > > I just spent the last half hour studying this and wrote my own concise legal > opinion arguing why GCUndoManager is OK. Now having read Graham’s post, it’s > probably redundant. But I’m posting it here anyhow in case I or anyone else > ever needs it :) > > Although -[NSUndoManager _processEndOfEventNotification:] is a non-public > API, -[GCUndoManager _processEndOfEventNotification:] is NOT a non-public > API. As a matter of fact, it is not even an Apple API! It’s the same as if > I defined a class CorePerformer and innocently named a method -[CorePerformer > _corePerformAction]. There also happens to be an Apple non-public method > -[NSMenuItem _corePerformAction]. Certainly my definition should not result > in an app store rejection. > ___ > > 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/rols%40rols.org > > This email sent to r...@rols.org ___ 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
Legal Opinion on GCUndoManager
On 2014 Jan 29, at 13:03, Keary Suska wrote: > unfortunately it [GCUndoManager] is not App Store safe … as it relies on a > private method call for proper NSDocument change tracking… I just spent the last half hour studying this and wrote my own concise legal opinion arguing why GCUndoManager is OK. Now having read Graham’s post, it’s probably redundant. But I’m posting it here anyhow in case I or anyone else ever needs it :) Although -[NSUndoManager _processEndOfEventNotification:] is a non-public API, -[GCUndoManager _processEndOfEventNotification:] is NOT a non-public API. As a matter of fact, it is not even an Apple API! It’s the same as if I defined a class CorePerformer and innocently named a method -[CorePerformer _corePerformAction]. There also happens to be an Apple non-public method -[NSMenuItem _corePerformAction]. Certainly my definition should not result in an app store rejection. ___ 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
