incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: [iOS] Going ARC
Date Thu, 10 May 2012 21:32:51 GMT
Resurrecting this. My latest comment (duped below):

D'oh - we can't have dual support of course, since this is compile
time and we ship a built binary for the framework. We'll have to turn
it on, and require ARC. The problem is, all the plugins will need to
upgrade as well.

This then becomes a communication issue that we will need to send to
devs ahead of time. We can push this to 2.0 but we must have an
extended RC period to iron out the bugs, but we can start blogging
about this change now.

If are to push it to now (1.8.0) my suggestion is to exclude ARC for
CDVPlugin, and instruct users how to exclude ARC for their plugin
- this way there is a transition. We can also print out warnings in
the console.log about the migration to ARC.


On Thu, Mar 8, 2012 at 2:58 PM, Shazron <> wrote:
> I'd rather not do #ifdefs and go whole hog on ARC. If we go ARC we
> can't support iOS 3.x (see my previous email).
> The #ifdef you would use:
> #ifdef __has_feature(objc_arc)
>    NSLog(@"ARC eh");
> #endif
> On Thu, Mar 8, 2012 at 12:16 PM, Patrick Mueller <> wrote:
>> On Thu, Mar 8, 2012 at 14:14, Shazron <> wrote:
>>> Ref:
>>> I say we go ARC.
>> I think we need to support ARC.  The question is do we need to support NOT
>> using ARC as well.
>> Presumably there's some pattern of leaving your retain/release calls in the
>> code, #ifdef'd, so they aren't used when your project is using ARC, and are
>> used when your project isn't.  Eventually, in theory, everyone is using ARC
>> all the time (just like we were going to use GC all the time!!), and we can
>> remove the #ifdef'y bits.
>> --
>> Patrick Mueller

View raw message