Objective-C Pitfall: Synthesized Properties without backing field
This is just a quick and short post about an Objective-C pitfall I have encountered today. When using synthesized properties, you do normally supply a backing field:
@property (nonatomic, readwrite, retain) Message* message = message_;
This will synthesize a getter and setter, that will use message_ as its backing field. Since I found out one can go clever and ommit the backing field, so a simple line like this will work too:
@property (nonatomic, readwrite, retain) Message* message;
However, now we get into a bit of trouble when accessing the property. Contrary to the behavior in Java or C#, you now get something different when accessing
self.message
vs.
message
. While the former will use the synthesized getter, the latter will use the synthesized backing field directly. This is a bit unexpected (I thought the backing field would be anonymous). So, my general advice would be to always use backing fields in your synthesized backing fields, so you don’t accidentally forget a “self.”. (This is water on the mills of people that advocate _not_ using the dot syntax for properties).
Leave a Reply
Reach me at:
My Stackoverflow Activity:
- How can I improve my first OSS project [closed]I am still visiting school and will finish my exams next year. Since two years I am working as (the only :-( ) in-house dev for a company providing financial services to Laboratories and doctors. After spending the first year fixing their existing Application and realizing, communicating and agreeing that it won't meet future requirements i rewrote it f […]
- CanActivate vs. CanActivateChild with component-less routesThe angular2 documentation about Route Guards left me unclear about when it is appropriate to use a CanActivate guards vs. a CanActivateChild guard in combination with component-less routes. TL;DR: what's the point in having canActivateChild when I can use a component-less routes with canActivate to achieve the same effect? Long version: We can have mul […]
- Spring Data Rest Adding Link to Root - RepositoryLinksResource cannot be cast to ResourceI'm trying to add a custom link to my API's root document, following this answer: Custom response for root request int the Spring REST HATEOAS with both RepositoryRestResource-s and regular controllers This is my custom resource processor: import org.springframework.data.rest.webmvc.RepositoryLinksResource; import org.springframework.hateoas.Link; […]
I didn’t know you were able to declare a backing field in the @property declaration.
Isn’t this the convention:
In .h file: @property (nonatomic, readwrite, retain) Message *message;
In .m file: @synthesize message = message_;
Then using self.message and [self message] will access the same iVar. No?
self.message and [self message] do never access an iVar directly, both of them will invoke the method with the name message on self. Rember that the dot-Notation (x.property) is just syntactic sugar for [x property].
The “convention” you listed is certainly fine and is what Google recommends in their Objective-C Style Guide. I use this when I do want to explicitly create an iVar.
The trick I presented in the post does not only synthesize the property, it also synthesizes the iVar. In this case you need to be aware of possible pitfalls.