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 shazron@gmail.com designates
 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <15115FEB-FF42-4D28-9AB2-69ECC5DE2264@gmail.com>
References: <FD267139-7577-44CD-84BC-B9817CC7FC50@jacobweber.com>
	<CABiQX1VrtG4TuQLQ_UhjCJ00O48PJW4AJ8o1ZDjR65siAbipzw@mail.gmail.com>
	<15115FEB-FF42-4D28-9AB2-69ECC5DE2264@gmail.com>
Date: Fri, 11 Jan 2013 10:34:50 -0800
Message-ID: 
 <CAE6O_-Zgwg096HS=xqs4eikAe4sei6tLMvT=_BOHWGffPQTuAQ@mail.gmail.com>
Subject: Re: Should Automatic Reference Counting be on?
From: Shazron <shazron@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=20cf3074b250ffe75e04d3078cac

--20cf3074b250ffe75e04d3078cac
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Actually Cordova core has been ARC for a couple of releases now. Good idea
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 an=
d
> non-ARC code, ARC is definitely easier on my brain cells -- I'm far too
> 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 Co=
re
> Foundation, and occasionally you run into more obscure problems (such as
> ARC releasing the object before the code expected it. Easy to fix, but no=
t
> 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 that
> 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 other?)
>
>
> On Jan 11, 2013, at 9:14 AM, Andrew Grieve <agrieve@chromium.org<javascri=
pt:;>>
> 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 some
> > plugins still do not support ARC.
> >
> > What are everyone's thoughts on how to address this? One option is to
> have
> > the default project template already set-up with two lib targets. One f=
or
> > 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<java=
script:;>>
> wrote:
> >
> >> When I create a new iOS project with Cordova 2.3, Automatic Reference
> >> Counting (CLANG_ENABLE_OBJC_ARC) is turned off. And the code (e.g.
> >> AppDelegate.m) uses autorelease, which I'm pretty sure is incompatible
> 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-counti=
ng-arc-and-cordova-plugins/
> >>
> >> Jacob
>
>

--20cf3074b250ffe75e04d3078cac--