Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.212.51 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CABiQX1XB5jywhtS_2Xf576A0J4CuSD0LJ3LeS=F1ZvMWFR=VSw@mail.gmail.com>
References: <FD267139-7577-44CD-84BC-B9817CC7FC50@jacobweber.com>
	<CABiQX1VrtG4TuQLQ_UhjCJ00O48PJW4AJ8o1ZDjR65siAbipzw@mail.gmail.com>
	<15115FEB-FF42-4D28-9AB2-69ECC5DE2264@gmail.com>
	<CAE6O_-Zgwg096HS=xqs4eikAe4sei6tLMvT=_BOHWGffPQTuAQ@mail.gmail.com>
	<CABiQX1XB5jywhtS_2Xf576A0J4CuSD0LJ3LeS=F1ZvMWFR=VSw@mail.gmail.com>
Date: Mon, 21 Jan 2013 11:03:00 -0600
Message-ID: 
 <CADVgkyPtXAiAQAzLyLftLwLvBC+_qpBbWQ5bkTe-Ony_XGCyoA@mail.gmail.com>
Subject: Re: Should Automatic Reference Counting be on?
From: Brian LeRoux <b@brian.io>
To: dev@cordova.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I say we roll w/ the assumption of #3 (but share your pragmatism that
#2 will likely result).

On Mon, Jan 21, 2013 at 10:27 AM, Andrew Grieve <agrieve@chromium.org> wrot=
e:
> Not sure how to move forward with this. I don't think that asking plugin
> devs to use macros to make their code work in both environments is
> reasonable. We don't do that in any of our core plugins.
>
> I don't think plugin devs will be motivated to update their plugins to us=
e
> ARC until we change the default template to use ARC, and they get users
> complaining.
> If not using two libraries, then setting -fno-objc-arc on each file *will=
*
> fix things, but it's not very obvious how to do that.
>
> Proposal #1:
> -We add a plugin-wide setting to plugin.xml that says whether the plugin
> uses ARC. We teach plugman to set the -fno-objc-arc flag for these. If th=
e
> plugin.xml ever changes this setting, then we need to edit the project fi=
le
> and remove the flag.
> -We don't change our default project template until CLI is our documented
> way of creating projects.
>
> Proposal #2:
> -We add a per-file setting to plugin.xml that says which files use ARC. W=
e
> teach plugman to set the -fno-objc-arc flag for these. If the plugin.xml
> ever changes this setting, then we need to edit the project file and remo=
ve
> the flag.
> -We don't change our default project template until CLI is our documented
> way of creating projects.
>
> Proposal #3:
> -We assume plugman-installable plugins use ARC
> -We don't change our default project template until CLI is our documented
> way of creating projects.
>
> I like #3 since it's simpler, but I'm afraid we'll have to support #2 in
> the end due to plugins that depend on third-party code.
>
>
> On Fri, Jan 11, 2013 at 1:34 PM, Shazron <shazron@gmail.com> wrote:
>
>> Actually Cordova core has been ARC for a couple of releases now. Good id=
ea
>> for the plugin tool default to non-ARC, this should be covered in the
>> spec...
>>
>> On Friday, January 11, 2013, Kerri Shotts wrote:
>>
>> > My two cents:
>> >
>> > If it's feasible to support ARC, I'd go for it. Having worked with ARC
>> and
>> > non-ARC code, ARC is definitely easier on my brain cells -- I'm far to=
o
>> > likely to leak memory like a sieve with manual memory management=85
>> >
>> > That said, converting Cordova's base code from non-ARC to ARC may not =
be
>> > trivial. In theory, you can just get rid of autoreleases, retains,
>> > deallocs, and handle properties (assign/retain/copy --> weak,strong), =
but
>> > sometimes you end up getting into toll-free bridging between Cocoa and
>> Core
>> > Foundation, and occasionally you run into more obscure problems (such =
as
>> > ARC releasing the object before the code expected it. Easy to fix, but
>> not
>> > always /obvious/ prior to experiencing the issue.)
>> >
>> > Once we have ARC support, though,  the -fno-objc-arc compiler flag is =
a
>> > per-file setting, so I would think that the plugin tools could set tha=
t
>> > flag based on whether or not the plugin supported ARC or not. (I would
>> > think this should be determined in the metadata somewhere? Perhaps
>> > defaulting to no-ARC if there's no metadata saying one way or the othe=
r?)
>> >
>> >
>> > On Jan 11, 2013, at 9:14 AM, Andrew Grieve <agrieve@chromium.org
>> <javascript:;>>
>> > wrote:
>> >
>> > > This caught me off-guard as well, and I filed an issue to fix it up:
>> > > https://issues.apache.org/jira/browse/CB-2180
>> > >
>> > > I don't think it'll be entirely straight-forward though, because som=
e
>> > > plugins still do not support ARC.
>> > >
>> > > What are everyone's thoughts on how to address this? One option is t=
o
>> > have
>> > > the default project template already set-up with two lib targets. On=
e
>> for
>> > > ARC and one without ARC. Another option is to instruct users how to =
set
>> > the
>> > > compile flag to disable arc on a per-file basis.
>> > >
>> > > Do we want to support ARC and non-ARC plugins in plugman?
>> > >
>> > >
>> > > On Thu, Jan 10, 2013 at 6:52 PM, Jacob Weber <jacob@jacobweber.com
>> <javascript:;>>
>> > wrote:
>> > >
>> > >> When I create a new iOS project with Cordova 2.3, Automatic Referen=
ce
>> > >> Counting (CLANG_ENABLE_OBJC_ARC) is turned off. And the code (e.g.
>> > >> AppDelegate.m) uses autorelease, which I'm pretty sure is incompati=
ble
>> > with
>> > >> ARC.
>> > >>
>> > >> Is this correct? Based on this blog post, I thought it should be on=
:
>> > >>
>> > >>
>> >
>> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-count=
ing-arc-and-cordova-plugins/
>> > >>
>> > >> Jacob
>> >
>> >
>>