On Aug 20, 2012, at 2:02 PM, Jens Alfke <[email protected]> wrote:
> On Aug 20, 2012, at 12:52 PM, I wrote:
>> My first thought was to declare some categories on NSArray and NSDictionary
>> to define those methods, but that's likely to cause issues when iOS 6 comes
>> out and already includes those methods — I'll get compile errors (which I
>> can work around with #ifdefs) but also a warning at launch time because the
>> methods are declared in two places.
>
> As an experiment I added the category @interface for these methods, but not
> the @implementation — the app still ran fine (at least in the 5.1 simulator;
> don't have an iOS 5 device to try it on right now.)
>
> My guess is that the compiler is smart enough to emit calls to e.g.
> objectForKey: instead of objectForKeyedSubscript: when it sees that the
> receiver is an instance of NSDictionary. But I haven't yet disassembled the
> code to verify this.
The compiler emits the same calls. The magic is in the increasingly
inaccurately named libarclite ("It's Not Just For ARC Anymore™"), which adds
implementations of the subscripting methods at runtime if they don't already
exist.
IIRC there are some subscript-able classes that libarclite does not upgrade
(NSOrderedSet, maybe?) so you still need to test thoroughly on older deployment
targets.
--
Greg Parker [email protected] Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
