Re: Legal Opinion on GCUndoManager
Re: Legal Opinion on GCUndoManager
- Subject: Re: Legal Opinion on GCUndoManager
- From: Uli Kusterer <email@hidden>
- Date: Sat, 01 Feb 2014 11:59:36 +0100
On 01 Feb 2014, at 01:02, Graham Cox <email@hidden> wrote:
> On 1 Feb 2014, at 4:32 am, Fritz Anderson <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden