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 (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/scottbayes-dev%40comcast.net >>> >>> This email sent to scottbayes-...@comcast.net >> >> _______________________________________________ >> >> 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/scottbayes-dev%40comcast.net >> >> This email sent to scottbayes-...@comcast.net > > _______________________________________________ > > 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/rowlandd%40sbcglobal.net > > This email sent to rowla...@sbcglobal.net _______________________________________________ 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
