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
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
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
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?
___
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
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 signat
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
