Re: Retain/Release and Properties clarification
Re: Retain/Release and Properties clarification
- Subject: Re: Retain/Release and Properties clarification
- From: Bayes Scott F <email@hidden>
- Date: Fri, 14 Oct 2011 10:29:08 -0700
Agreed.
I just meant in the general case.
ScottB
On Oct 13, 2011, at 11:30 , David Rowland wrote:
> However, if the property is readonly I think you must use direct access to set an initial value. The setter does not exist.
>
>
> David Rowland
>
> On Oct 13, 2011, at 10:54 AM, Bayes Scott F wrote:
>
>> Thank you, David.
>>
>> Sounds like safety first for my code: always use the setter/getter for synthesized properties, even in self.
>>
>> Or use ivars.
>>
>> ScottB
>>
>> On Oct 12, 2011, at 09:21 , Bayes Scott F wrote:
>>
>>> Someone on Matt's site mentioned the possibility that the synthesized ivar could be implemented indirectly, say as a member of a collection. Since the implementation's opaque, we don't know if that ever can happen.
>>>
>>> So, is self->mySynthIvar safe (both lvalue and rvalue), or should we be messaging?
>>>
>>> And does the compiler ever shortcut something like self.mySynthSimpleIntVar to self->mySynthSimpleIntVar, or does it always use the setter/getter?
>>>
>>> Thanks
>>>
>>>
>>> ScottB
>>>
>>> On Oct 11, 2011, at 10:12 , David Duncan wrote:
>>>
>>>> On Oct 11, 2011, at 9:57 AM, Matt Neuburg wrote:
>>>>
>>>>> I did everything "right" when I named an ivar "firstResponder" (property, synthesized ivar, synthesized accessors) and totally broke my app because Apple was apparently already using an undocumented ivar called "firstResponder".
>>>>>
>>>>> http://www.cocoabuilder.com/archive/cocoa/296662-assign-property-behaves-differently-from-simple-instance-variable.html
>>>>
>>>> The problem wasn't an undocumented ivar, it was an undocumented method. The @synthesize thus overrode the existing method and broke your project because parts of UIKit were expecting the default implementation and got your implementation instead.
>>>>
>>>> As a rule, we strive to avoid this situation, but unfortunately this does happen on occasion.
>>>>
>>>>> Also, note that there are circumstances where a synthesized ivar won't work; see, for instance, this note:
>>>>>
>>>>> http://www.cocoabuilder.com/archive/cocoa/298320-inherited-implicitly-created-member-is-no-member.html
>>>>
>>>> The gist of this is that synthesized ivars are private, and the public interface (the @property) doesn't tell you about private implementation details (the ivar). As such, subclasses can't get at synthesized ivars, precisely because the @synthesize declaration is hidden from them.
>>>> --
>>>> David Duncan
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (email@hidden)
>>>>
>>>> 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:
>>>>
>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden