incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [iOS] Going ARC
Date Thu, 08 Mar 2012 20:39:32 GMT
ARC benefits, less code, cleaner code, simpler code
ARC downsides - anal memory management folk won't be able to use it (
non-ARC applications cannot load an ARC library, it is all or nothing. )

The only way to support both is to do both ... ie conditional code, #ifdef
bs that I personally think will make BOTH paths suck.

My vote is to go the ARC route (exclusively)



On Thu, Mar 8, 2012 at 12:23 PM, Filip Maj <fil@adobe.com> wrote:

> What are the down-sides, if any, to moving to ARC? Potential for not being
> "as optimized"? Not sure how much that matters to the typical
> lists-n-buttons app that most Cordova apps are.
>
> And up-sides? Less/cleaner/easier code?
>
> On 3/8/12 12:16 PM, "Patrick Mueller" <pmuellr@gmail.com> wrote:
>
> >On Thu, Mar 8, 2012 at 14:14, Shazron <shazron@gmail.com> wrote:
> >
> >> Ref: https://issues.apache.org/jira/browse/CB-274
> >>
> >> 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
> >http://muellerware.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message