On 22 Dec 2011, at 2:05 PM, Kyle Sluder wrote:

> On Thu, Dec 22, 2011 at 11:29 AM, Fritz Anderson
> <fri...@manoverboard.org> wrote:
>> The document's NIB (no, I don't put the document in the NIB, and I'm using 
>> the window controller that comes with the document) contains an 
>> NSObjectController and an NSArrayController at the top level. Per "Patterns 
>> for Managing Outlets Become Consistent Across Platforms" in the 
>> "Transitioning to ARC Release Notes," the IBOutlet properties for those 
>> controllers were declared strong.
> 
> This seems to conflict with the Resource Programming Guide, which
> recommends that your IBOutlets be declared weak (aka 'assign') on Mac
> OS X: 
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW26

I don't take your point. The "_become_ consistent" part of the title implies 
that the new recommendation, that outlets to top-level objects be strong, is 
_new_. 

On the page you refer to, I see:

"You typically need strong references to top-level objects to ensure that they 
are not deallocated…. From a practical perspective, in iOS and OS X outlets 
should be defined as declared properties. Outlets should generally be weak, 
_except for those from File’s Owner to top-level objects in a nib file … which 
should be strong_."

Emphasis added. The example given (twice) is:

        @property (strong) IBOutlet MyOtherClass *topLevelObject;

"Outlets should be changed to strong when the outlet should be considered to 
own the referenced object:

        • As indicated previously, this often the case with File’s Owner—top 
level objects in a nib file are frequently considered to be owned by the File’s 
Owner."

However, I do see the section on "_Legacy_ Patterns," which does recommend 
assign on Mac OS X, "_prior to ARC_." I am using ARC. On the other hand, I'm 
using it on a 10.6 target. 

ON STILL THE OTHER HAND, there is the section "Top-level Objects in OS X May 
Need Special Handling," which prescribes a horrific little ARC dance (HLAD, I'm 
trying to popularize it) you have to do in order to CFRelease top-level 
objects, because top-level objects come in with ownership +1. (But, but, but… I 
thought Mac OS NIB loading had been made consistent with iOS, like the ARC 
release note said?)

The more I go through of this, the more confused I become — and a year ago, I 
was pretty confident I knew this stuff.

None of this answers my question, which apparently I should have made clearer:

====
In a 10.6-targeted application (possibly running on 10.7), using ARC, do 
top-level objects follow the "ARC rule" (as in the release notes), or the 
"prior to ARC" rule (even though the code uses ARC)?
====

Maybe I have to have another look at that horrific little ARC dance. If that's 
necessary, then I was wrong to declare the object-controller outlets u_u, they 
should be strong, and I should then do the HLAD.

        — F

_______________________________________________

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Reply via email to