I'm using AppCode and it flagged an interesting situation in the code of a very large project. Pre-ARC.
A subclass defines and synthesizes a property called delegate. Actually the property declaration had been commented out! But the #synthesize delegate = delegate_; statement was left behind.
The code compiles, presumably because the base class defines and synthesizes a property also called delegate and synthesizes it with a backing variable with the same name: #synthesize delegate = delegate_;
My question is: What happens with a message is sent to the delegate in
a) the base class methods and
b) in the sub-class methods.
AppCode flags the synthesize statement in the sub-class as an error:
Accessors of property 'delegate' were already synthesized with
instance variable 'delegate_'
The #synthesize directive is shorthand for creating accessor methods and an ivar according to the specifications (atomicity, memory management) of the property of the same name. Given that, re-synthesizing a property in a subclass (without re-declaring it) works exactly like overriding the accessor methods -- the subclass's implementations are used instead of the superclass's. Since the implementations are created by the compiler in both cases, there's no noticeable difference in behavior.
The one difference is that a synthesized ivar has the same visibility as a #private ivar, so subclasses can't access it, including to use it as the backing variable for a property. This means that the re-synthesis in the subclass must use a different ivar name. If the superclass has #synthesize wildHorses = wildHorses_;, then the compiler requires the subclass to do something like #synthesize wildHorses = equusFerus;.*
*If the superclass uses the default name for the created ivar, #synthesize wildHorses; then the subclass must still synthesize a new variable: #synthesize wildHorses = wildHorses_;
Related
I declared one property in a class:
#property double x;
Then I made a subclass of that class in which I declared two more properties:
#property double a, b;
Then I made an init method in the subclass:
-(id)initWithAValue:andBValue:
And I am allowed to use:
_a; // same for b
[self setValue a]; // same for b
self.a; // same for b and x
Now, when I try to use the x property, I can only use [self setValue x] and I can't use _x. Why?
You are able to get/set the property, you just can't directly access the instance variable/backing store behind it, which you typically don't do anyway even when they belong to the subclass.
_x is the instance variable or ivar.
self.x is the property, accessed via getter/setter methods created when you use #property to declare x.
When you use #property (previously used with #synthesize, no longer required) it auto-generates the getter, setter, and backing ivar. The ivar itself, depending on where it's declared is created either as #protected or #private. Responses to this question, while a bit old, give some insight to the different visibility modifiers.
If you declare #property double x in your public .h file, it will be #protected by default, meaning that both the accessor methods and the ivar should be visible to instances of the superclass and subclasses, but not to instances of other outside classes.
If you declare that same #property in a class extension or the #implementation block in your .m (exposing only what you really need to), it's #private by default, meaning the ivar is only accessible by instances of that exact class - not subclass instances. This leaves only the getter/setter methods exposed to the subclass.
You can override these defaults if you choose, but generally it's preferable to use accessor/mutator methods & not deal directly with ivars. This is by design, since you want to control exactly how other objects, even subclass instances, can access/manipulate your variables.
appDelegate.h
#property (readonly, strong, nonatomic) NSManagedObjectContext *managedObjectContext;
I had to do this in appDelegate.m
#synthesize managedObjectContext = _managedObjectContext;
I'm confused because according to apple
Note: The compiler will automatically synthesize an instance variable
in all situations where it’s also synthesizing at least one accessor
method. If you implement both a getter and a setter for a readwrite
property, or a getter for a readonly property, the compiler will
assume that you are taking control over the property implementation
and won’t synthesize an instance variable automatically. If you still
need an instance variable, you’ll need to request that one be
synthesized: #synthesize property = _property;
According to this it should create an instance variable as long as it created at least one accessor method. So does this mean that no accessors methods where created when I declared the property? What is the reason. Please explain.
I'm assuming somehow the compiler knows that NSManagedObjectContext has accessor methods. So it didn't create any and therefor it didn't create instance variables.
You haven't shown the code for the corresponding .m file, but I'm assuming you implemented the managedObjectContext property getter method programmatically. As the documentation says, "The compiler will automatically synthesize an instance variable in all situations where it’s also synthesizing at least one accessor method." But if you provide an implementation of the getter method for a readonly property, the compiler isn't synthesizing any accessor methods.
As the documentation says...If you provide atleast one accessor method for either setter or getter, its like telling the compiler...dont bother synthesizing this variable as I have some custom work to do with the setter/getter. Hence the compiler does not auto generate the _ivar. If you need the _ivar, you have to explicitly specify it and then proceed with your customer getter and setter. Its all about Objective C compiler doing things for you unless you say Don't bother...I know what I am doing.
I want to ovveride getter for lazy instantiation and leave default setter.
Do I need #synthesize ?
Why ?
#interface Foo()
#property (strong, nonatomic) NSObject *bar;
#end
#implementation Foo
- (NSObject *)bar
{
if(!_bar) _bar = [[NSObject alloc] init];
return _bar;
}
#end
Update: I've changed variable and class name, because it was confusing. From Deck and card to Foo and bar.
No, you only need to explicitly synthesize (to get the synthesized ivar) if you explicitly implement all of the accessor methods (both getter and setter for readwrite properties, just the getter for readonly properties). You've written the getter for this readwrite property, but not the setter, so the ivar will still be synthesized for you. Thus, as your code stands, you do not need to explicitly #synthesize.
If you made this property readonly, then implementing a getter would prevent your ivar from being automatically synthesized. Likewise, since this is readwrite, if you implemented both the getter and the setter, that would require you to synthesize the ivar (if you wanted one).
Don't use lazy initialization this way. A Deck is useless without cards and, thus, lazy initialization buys you nothing but an indeterminate consumption of CPU whenever the first call to that getter might be. Fortunately, simply creating a mutable array costs nothing (which is also a reason not to use lazy initialization).
As well, vending a mutable collection breaks encapsulation. A Deck should contain all the logic for determine what set of Cards it contains and in what order. By vending a mutable collection, an external bit of code can change that order behind the Deck's back.
Beyond that, what does it even mean to "set" a Deck's cards? Going that route seemingly pushes all logic related to maintaining the Deck outside of the Deck class, begging the question as to why the deck is nothing more than a plain old array in whatever class uses the deck.
In iOS 7, you don't normally need synthesize. If you want a custom getter, just define one. You'll get the default setter for free.
I'm a bit confused; if an object is declared in the .h file it is considered automatically as "public" right? We use a #property in the .h file, however, to edit them? This is where I don't understand: we use the getter/setter for private objects, so why do we use the #property for objects declared in the .h file and thus considered as "public"?
Second thing, I found this example: I don't understand why we use a #synthesize for primaryKey in this code: http://staging.icodeblog.com/wp-content/uploads/2008/08/9-todom1.png
and why we don't use a #property for the database object?
It is not correct that if an object (ivar) is declared in a .h file, then it is public. It is only if getter/setter methods are provided, otherwise it is not.
Indeed, the #property/#synthesize directives are facilities meant to declare and define default getter/setter methods. So, instead of writing them yourself, you just use the directives.
It is also worth noting that declaring properties you get the possibility of using the dot notation to refer properties of your objects. And also that they clarify a lot, thanks to the retain/assign/copy specifiers, how memory is meant to be managed for that properties. (And, of course, #synthesize will just do that correctly for you).
About your sample, in fact, whether an ivar is associated to a property or not is a design choice. Possibly, you just reconsider the assumption that ivars declared in .h files are public by defaults, and it will become clearer. In other words: primaryKey is public, database is not.
A very nice tutorial can be found here but also do not forget Apple docs.
EDIT:
about your question from the comment section:
it is not necessary that every ivar has a property, nor that it has getter/setter in order to be used inside of that class implementation.
#interface SomeClass : NSObject {
AnotherClass* _anotherClassObj;
AThirdClass* _aThirdClassObj;
}
#property (nonatomic, retain) AnotherClass* anotherClassObj;
#end
So, here you have two ivars; only one has got a #property declaration. In your .m file you may have, e.g.
#implementation SomeClass;
#synthesize anotherClassObj = _anotherClassObj;
- (void)initWithClasses:(AnotherClass*)obj1 and:(AThirdClass*)obj2 {
.....
self.anotherClassObj = obj1;
_aThirdClassObj = obj2;
...
}
....
#end
In this code:
#synthesize will provide implementation for getter/setter for anotherClassObj so you can use syntax: self.anotherClassObj = obj1; that syntax can be used equally from inside and outside the class implementation;
when you have no getter/setter (either auto-generated or custom) you can assign directly to an ivar by using the syntax _aThirdClassObj = obj2;, with the semantics of simple pointer copy; anyway, _aThirdClassObj will not accessible from outside that class;
furthermore, #property ... anotherClassObj notwithstanding, you can still refer _anotherClassObj directly in your .m file, like in _anotherClassObj = xxx, bypassing getter/setter, if you ever need it.
One thing you should have clear is that getter/setter are not only a way to make an ivar "public". They also play an important role in managing the retain count (depending on which specifier you choose among retain/assign/copy in the property declaration). So, in self.anotherClassObj = obj1; above, obj1 is assigned to _anotherClassObj and it is also retained (and if _anotherClassObj was previously pointing to an object, that object will be sent a release). Raw ivar assignment does not provide that kind of facility.
In my opinion, the retain count management feature of properties is far more important than visibility for deciding whether I use a property or not.
Not everything in the header is public, by default ivars (items in the { }) are #protected. The purpose of the #property is data encapsulation. #synthesize or #dynamic is used for declaring the way you want to implement your property and one or the other is necessary to prevent crashes and warnings.
Resources:
Defining Classes #protected, #package, #private, #public reference
Declared Properties #property reference
The Scenario
I have a situation where a base class called AbstractRequest has a delegate property of type id <AbstractRequestDelegate> declared in the header file:
#property (nonatomic, assign) id <AbstractRequestDelegate> delegate;
The abstract delegate protocol contains a few required methods, and as indicated with the word 'abstract', both the AbstractRequest and the AbstractRequestDelegate are intended to be subclasses/extended.
One example of this would be the subclass ConcreteRequest and extended protocol ConcreteRequestDelegates, that both add extra methods to the abstract ones. The intention is that both the abstract and concrete class methods can send messages to the single assigned delegate instance.
At a certain point in time the ConcreteRequest would like to call a method on the delegate that is defined by ConcreteRequestDelegate. Because the type of the delegate is id , the compiler will give a warning that this method might not be implemented.
ConcreteRequest.m:38: warning:
property 'delegate' requires method
'-delegate' to be defined - use
#synthesize, #dynamic or provide a
method implementation
The Problem
This warning is justified, for the property is after all typed to id <AbstractRequestDelegate>. In order to fix this, I want to make clear to the compiler that the delegate assigned to the concrete instance must be of type id <ConcreteRequestDelegate>. This sounded perfectly reasonable to me, so I put in a new property in the ConcreteRequest header, hoping to override the abstract one:
#property (nonatomic, assign) id <ConcreteRequestDelegate> delegate;
But this is where the compiler disagrees with me, probably with good reason. I would have thought it would give a warning for overriding a super class' property with the wrong type, but instead it just demands me to re-synthesize this new property. I don't want to go there, because then the super class' methods won't have access to the same delegate property.
The Question
Is there a way to 're-declare' the property in the concrete subclass with the added type information? Or can you spot the error in my thinking, for maybe this is a fairly common problem that I just haven't come across until now?
Cheers,
EP.
P.S. All class and protocol names appearing in this work are fictitious. Any resemblance to real class and protocol names, open source or patented, is purely coincidental.
The warning already gave the right clue. I used #dynamic in the overriding subclass and all is good.
Just synthesize id<ConcreteRequestDelegate>delegate in the ConcreteRequest.m it will work fine...It won't create any problem.