Re: ARC code in a non ARC app. iOS

[Dave]

> On 24 Feb 2016, at 23:57, Greg Parker  wrote:
> 
> 
>> On Feb 24, 2016, at 2:31 AM, Dave  wrote:
>> 
>> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to 
>> have the subclass Non-ARC too.
> 
> This is not true. For example, NSView is not ARC but you can write ARC 
> subclasses of it.

I didn’t say it was impossible, but depending on what the class does and how 
it’s implemented can cause problems……..
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Jens Alfke]

> On Feb 25, 2016, at 8:35 AM, Dave  wrote:
> 
>>> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to 
>>> have the subclass Non-ARC too.
>> 
>> This is not true. For example, NSView is not ARC but you can write ARC 
>> subclasses of it.
> 
> I didn’t say it was impossible, but depending on what the class does and how 
> it’s implemented can cause problems……..

You did say “you have to have the subclass Non-ARC”, which to me sounds like 
“it’s impossible”.

And I can’t think of any way that a (properly implemented) non-ARC class could 
cause problems for an ARC subclass. A class’s or method’s behavior doesn’t 
change depending on whether its implementation uses ARC. Do you have any actual 
examples of problems?

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Dave]

> On 25 Feb 2016, at 17:43, Jens Alfke  wrote:
> 
> 
>> On Feb 25, 2016, at 8:35 AM, Dave > > wrote:
>> 
 Also, beware subclassing a Non-ARC Class in an ARC Project - you have to 
 have the subclass Non-ARC too.
>>> 
>>> This is not true. For example, NSView is not ARC but you can write ARC 
>>> subclasses of it.
>> 
>> I didn’t say it was impossible, but depending on what the class does and how 
>> it’s implemented can cause problems……..
> 
> You did say “you have to have the subclass Non-ARC”, which to me sounds like 
> “it’s impossible”.

Sorry, I just re-read it and it was supposed to read *may* have to…..

> And I can’t think of any way that a (properly implemented) non-ARC class 
> could cause problems for an ARC subclass. A class’s or method’s behavior 
> doesn’t change depending on whether its implementation uses ARC. Do you have 
> any actual examples of problems?
> 
> —Jens

Somewhere but it is back in the distant git-past and probably not that easy to 
find and I can’t remember why I had to do it now, something to do with 
properties and/or IVs. It may well have been possible to do it another way, but 
the easiest seemed to be to make it non-ARC too.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Changing timing for looping uiview animation

[Eric Dolecki]

I have a heart rate looping scaling animation. 
Every 5 seconds I get new data. How can I adjust the looping scale rate without 
removing the animation before setting the new rate without hiccups?

Sent from Outlook on my phone.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Uli Kusterer]

On 24 Feb 2016, at 00:47, Quincey Morris  
wrote:
> For example, an object obtained via [[…alloc]init…] is generally assumed to 
> be returned with a +1 ownership, but an object obtained via a class method 
> named ‘newXXX…’ is generally assumed to be returned with +0 ownership.

 Did you really mean +newBlah ? Not something like +blahWithX: or just +blah? 
Because +new is documented to just be a shorthand for +alloc followed by -init 
on the result, so +newBlah behaving differently than +new sounds kinda 
inconsistent to me. Did I miss a serious gotcha there?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Quincey Morris]

On Feb 25, 2016, at 22:15 , Uli Kusterer  wrote:
> 
> Did you really mean +newBlah ? Not something like +blahWithX: or just +blah? 
> Because +new is documented to just be a shorthand for +alloc followed by 
> -init on the result, so +newBlah behaving differently than +new sounds kinda 
> inconsistent to me. Did I miss a serious gotcha there?

No, you’re correct. I was making a valid point using the wrong example.

As you said, if the name of a class method begins with “new”, it belongs to the 
“new” family, and it’s implicitly marked with 
'__attribute__((ns_returns_retained))’. That means it has +1 semantics.

What I was actually thinking of was factory methods that *don’t* begin with 
“new”, such as -[NSArray array]. These typically have +0 semantics. My point 
(which I think I’ve now demonstrated pretty vividly) is that if you don’t 
remember what the conventions are, it’s easy to go wrong in MMR.

Interestingly, in the old days, people argued about whether to do [[NSArray 
alloc] init] or [NSArray array], based on clarity vs. efficiency (avoidance of 
an autorelease). As soon as ARC took charge, no one cared any more, because ARC 
offered at least the possibility of both forms being efficient at run time. Now 
that we have conversions into Swift, using compatible naming of factory methods 
is important again. Plus ça change, …

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Uli Kusterer]

On 24 Feb 2016, at 00:25, Alex Zavatone  wrote:
> Would it be recommended to package my ARC code with ARC turned off and 
> package that in a framework and then link to that from the non ARC app that 
> will need to load it?

 Nope, that would leak all over the place, or dangle pointers depending on 
whether you're prone to using alloc/init and new to create your objects, or 
factory methods.

 Think of ARC this way: ARC manages memory for you (except for circles of 
strong references, aka retain cycles, those you have to resolve by marking 
back-references as weak) inside ARC-using source files. Basically, it inserts 
the requisite retain/release calls for you. So, once generated, ARC code is 
(for all we care for this discussion) undistinguishable from non-ARC code.

 However, you need to help ARC at the bridging point between ARC and non-ARC by 
following ObjC's naming conventions, and also by properly marking references as 
strong or weak. For your non-ARC classes that are referenced by ARC, this means 
if you have a -copyMachine factory method, ARC will see the "copy" and assume 
it's a method with copy semantics instead (+1 reference returned), and end up 
over-releasing the +0 reference of the factory method. The other way round is 
similar. If you create a -copyMachine method, ARC will just return a +1 
reference from it and any other code using it must release it once done to 
avoid leaking.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com