incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: [iOS] Going ARC
Date Thu, 08 Mar 2012 20:44:24 GMT
+1 going exclusively ARC

On 3/8/12 12:39 PM, "Jesse" <purplecabbage@gmail.com> wrote:

>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
View raw message