So here's what I know about properties in Objective-C. Please correct me if these are not facts.
When declaring a property you are declaring the setter/getter for a instance variable
If you want to have the setter and getters defined you need to synthesize them
If you synthesize, the instance variable is defined for you. Best practice is to rename the iVar so that the getter and iVar aren't the same name. So you usually do:
#synthesize myVar = _myVar
All of my knowledge about properties is coupled with instance variables. I've watched some videos recently that say properties can be used for other instance methods besides setters/getters.
Is this true? If so, how and why would you use a property in this way? For instance I was watching a Stanford cs193p video about protocols and it said that you could have a prototype in a protocol. I could of misunderstood.
Anyways thanks to those who respond
When declaring a property you are declaring the setter/getter for a instance variable
No, you are declaring a getter and possibly a setter of a property. Period. Declaring a property does not itself imply an instance variable. There are many ways to implement a property. Instance variables happen to be a common and popular way, but non-ivar properties are very common.
If you want to have the setter and getters defined you need to synthesize them
No. (As sergio points out, I originally confused "defined" and "declared.") Almost. The #property line itself declares the setter and getter. If you want to have the setter and getter implemented for you, that is called "synthesize," but you no longer need to do this manually. The complier will automatically create a getter and setter for any property that you declare but do not implement (unless you explicitly ask it not to using #dynamic).
If you synthesize, the instance variable is defined for you. Best practice is to rename the iVar so that the getter and iVar aren't the same name. So you usually do: #synthesize myVar = _myVar
Almost. This was true a few months ago, but you no longer need to actually do that #synthesize. It will be done automatically for you by the compiler now.
This header:
#interface MyObject : NSObject
#property (nonatomic, readwrite, strong) NSString *something;
#end
is almost the same as this header:
#interface MyObject : NSObject
- (NSString *)something;
- (void)setSomething:(NSString *)something;
#end
There are some very small differences between these two, some related to the runtime and some related to the compiler, but it is clearer if you just pretend they're identical.
All you're doing in both of these cases is declaring some methods. You are not declaring how they're implemented. You're not declaring ivars. You're just declaring methods. You are now free to implement those methods any way you like. If you like, you can implement them by letting the compiler synthesize some default implementations for you. If you like you can implement them by hand. You can do one of each if you like.
Properties are synthesized by default since Xcode 4.4. So you only need to declare the property (myVar).
There will also be a _myVar available that you may use instead of accessing self.myVar.
Using a properties as a parameterless methods is torsion them into a something they are not.
Related
I have been programming for the iOS platform for the last few years but mainly using swift. In the recent months though, I have been tasked with a project using Objective C, and while I like it and found it easy to learn, there are some questions mainly about variables that I still don't quite understand.
1) What is the difference between declaring an instance variable and a property? Since the compiler automatically creates an instance variable for every property, is there any real advantage besides being able to pass in some parameters like atomic, nonatomic, strong, weak, assign, etc?
2) What is the difference between declaring variables in the #implementation or properties #interface inside the .m file?
From what I understand, declaring in the #implementation makes it a static variable and declaring it in the #interface makes it an instance variable, is that correct? Also why do classes that inherit from UIViewController (for example) already have an #interface in the .m file and classes that inherit from NSObject don't?
3) (Personal Question) Do you usually set a property to be atomic or nonatomic? I find that atomic is better because while it may be slower it is thread safe, but I see most people using nonatomic. Is the speed difference still noticeable nowadays with the amount of power we have?
4) Whenever I declare two instance variables with the same name in the #implementation in two different classes I get a "duplicate symbol" error. Why does this happen?
Just another simple question out of curiosity:
I see many questions where in the code the #interface has curly braces, but in my code I've never seen it, rather it ends with a #end like the #implementation file. Was this in earlier versions of Obj-C or is there any real difference?
Thank you so much, I know these are 4 or 5 questions, but I jumped so quickly into a project and I think I really need to learn the basics, which I skipped because I could not find answers to this questions.
1) What is the difference between declaring an instance variable and a property? Since the compiler automatically creates an instance variable for every property, is there any real advantage besides being able to pass in some parameters like atomic, nonatomic, strong, weak, assign, etc?
A property may or may not be backed by an instance variable. By default they are but you can declare a property and the explicitly provide both a getter and setter (if not read-only). Then the property will not have an implicitly declared ivar. Properties make it easy to indicate whether it is atomic or not, whether it is read-only or not, and it lets you indicate the memory management (strong, weak, copy, assign). Properties also provide support for key-value observing.
If you want a simple variable used privately without the need for any of those features, then a direct ivar without a property is over so slightly more efficient.
See Is there a difference between an "instance variable" and a "property" in Objective-c? for more details.
2) What is the difference between declaring variables in the #implementation or properties #interface inside the .m file? From what I understand, declaring in the #implementation makes it a static variable and declaring it in the #interface makes it an instance variable, is that correct? Also why do classes that inherit from UIViewController (for example) already have an #interface in the .m file and classes that inherit from NSObject don't?
The private #interface Whatever () in the .m is known as the class extension. It's basically a special unnamed category. There is no difference between declaring ivars there or in the #implementation block.
Personally I use the class extension to privately conform to protocols and to declare private properties. I use the #implementation block to declare private ivars.
Variables in the #implementation block are normal instance variables if they are put in the curly braces.
#implementation {
// ivars here
}
// variables here are globals. Same as before #implementation or after #end
// methods
#end
Without the curly braces those variables become globals.
See Difference between variables in interface Object() {} and #implementation Object #end and Difference Between Declaring a Variable Under #Implementation And #Interface Under .m file for more details.
3) (Personal Question) Do you usually set a property to be atomic or nonatomic? I find that atomic is better because while it may be slower it is thread safe, but I see most people using nonatomic. Is the speed difference still noticeable nowadays with the amount of power we have?
Atomic properties are not really thread safe. It just means the assignment is atomic and a read is atomic but it doesn't really mean thread safe in the broader sense.
See What's the difference between the atomic and nonatomic attributes? for a much more thorough discussion.
4) Whenever I declare two instance variables with the same name in the #implementation in two different classes I get a "duplicate symbol" error. Why does this happen?
See #2. You must not have your variables in the #implementation block curly braces. Put the variables where they belong and the problem goes away.
If you actually want the variable to be a file static, put it before the #implementation to make it clear that it isn't part of the class and prefix the variable declaration with static. Then if you happen to have two with the same name in different files, there won't be a duplication problem if they are static.
1) What is the difference between declaring an instance variable and a property? Since the compiler automatically creates an instance variable for every property, is there any real advantage besides being able to pass in some parameters like atomic, nonatomic, strong, weak, assign, etc?
Properties are really just methods wrapped in a syntax. They're intended to be called by other classes, assuming they're publicly provided. Instance variable is more like a field access in C. You should probably default to using properties (they support KVO, are safe on nil, etc.). You should certainly default to using properties for getting/setting, except possibly in the initializer.
Note, though, that the compiler does not always create instance variables. If you provide both getter and setter, you'll need to tell it to with #synthesize foo=_foo;.
2) What is the difference between declaring variables in the #implementation or #interface inside the .m file? From what I understand, declaring in the #implementation makes it a static variable and declaring it in the #interface makes it an instance variable, is that correct? Also why do classes that inherit from UIViewController (for example) already have an #interface in the .m file and classes that inherit from NSObject don't?
Historically, instance variables could only be defined in the #interface.
3) (Personal Question) Do you usually set a property to be atomic or nonatomic? I find that atomic is better because while it may be slower it is thread safe, but I see most people using nonatomic. Is the speed difference still noticeable nowadays with the amount of power we have?
The reason for using nonatomic is that atomic doesn't really solve thread safety as much as you'd think. For example, this is still thread unsafe, even if the property is set to atomic (since the value of foo could change between the read and write):
self.foo = self.foo + 1;
For this reason I think most favor nonatomic and handling thread safety specifically when needed.
I am new in objective c and I have some doubts. I've seen that you can access to the properties of a class like var->myProperty and like that too variable.myProperty, but I do not know what the difference between the 2. I searched a lot in internet and really have not found a conclusive answer.
Sorry if I have spelling errors, thanks in advance.
There are three cases to consider:
use of someObject.something
use of self->something
use of otherObject->something
someObject.something is the dot syntax. It is exactly equivalent to [someObject something] in terms of behavior. It is a method call. Note that something does not have to be declared via an #property. That is, someArray.count or someString.length are both syntactically valid.
self->something is accessing an ivar directly. It is a very rarely used syntax; rare is in pretty much never. Instead, just access the ivar directly using something = or [something doSomething]. No need for the ->.
otherObject->something is grubbing around otherObject's instance variables directly. Bad programmer. No donut. Don't do that. It breaks encapsulation and leads to extremely fragile, hard to maintain, code.
A note on #property declarations. If you have:
#property (atomic, strong, readonly) SomeClass *foo;
And if you let the compiler automatically #synthesize everything, it will create an instance variable named _foo.
You should use direct access in your init and dealloc methods, but -- typically, though not always -- use the setter/getter everywhere else. I.e. in your init you would do _foo = [SomeClass someClassWithSomeMagicValue:42] (assumes ARC, so no retain needed). Everywhere else, you would do [[self foo] castMagic];.
The obj->foo syntax accesses the ivar foo of obj whereas obj.foo accesses the property (defined by #property). The main difference is that obj->foo does not use any getters/setters and writes to the ivar directly.
For example, if you defined the property like this
#property (atomic, strong, readonly) SomeClass *foo;
Modern Objective-C compilers will automatically create an ivar _foo and the property foo for you (without the need of declaring the ivar and #synthesizeing the property.
obj.foo will then automatically use the atomic getter and will make the property readonly (ie no setter). Using the ivar syntax obj->_foo, you are reading the property non-atomically(!) and you can even write it (remember, the property is readonly!).
Usually it's very easy: Always use the property syntax, except in init and dealloc, there you use the ivar syntax. Obviously when you are actually implementing a getter or a setter yourself, that's another place to use the ivar syntax. (thanks to #godel9). (Remember: That's a rough guideline, there are other use-cases where you might want direct ivar access).
EDIT: Because of some critique in the comments: It's true that the dot syntax can also be used without declaring something as #property, eg some use array.count instead of [array count] (for NSArray *array). But given that the OP asked about properties vs ivars, that was certainly not asked. Also note that for a given #property ... SomeClass *foo the ivar is not necessarily _foo but that's would be the auto-generated ivar name in recent ObjC compilers (with #synthesize you can map properties to arbitrary ivars).
look at Pointers in objective-c
http://www.drdobbs.com/mobile/pointers-in-objective-c/225700236
With the current version of Objective-C, what are the official standards and best practices for declaring ivars, using #property and #synthesize? There are a lot of posts and resources on the topic but most of them are fairly antiquated from a year or two ago. I recently learned to only declare ivars in a statement block in the implementation of a class so that the encapsulation principles of OOP aren't broken but is declaring ivars even necessary in this day and age? What would be a possible use case where doing:
#interface MyClass()
#property (nonatomic) NSString* data;
#end
#implementation MyClass{
#private
NSString* _data;
}
#end
is necessary? To further that, is it ever necessary to use #synthesize? My understanding is that using #property will auto-synthesize both the accessor methods as well as the backing ivars. I've done some experimentation and I noticed that when I don't declare NSString* _data', I can still access_data' in my class implementation. Does that mean that declaring ivars come down to a matter of style, up to the discretion of the programmer? Could I condense my code and remove all ivar declarations in the statement blocks in my implementation and just use #property in my private interface? If that's not the case, what are the advantages and disadvantages of explicitly declaring ivars?
Finally, #dynamic. From what I can gather, it's used to say to the compiler, "Hey compiler, don't auto-generate the accessor method and don't worry if you don't find an implementation for it, I'll provide one at runtime". Is that all #dynamic is used for or is there more to it?
I just want to clarify all these things because it seems like there's a lot of different opinions and that there's not necessarily one right answer. Plus as Objective-C grows and progresses, those answers will change so it'll be nice to have a concise and up-to-date guide. Thanks everyone!
(Also if there's anything that I could word better or make clearer, let me know)
EDIT:
In summary, what I'm asking is this:
1) Is declaring ivars with modern Objective-C necessary?
2) Can I achieve the same effects of declaring ivars and corresponding properties by just using #property?
3) What is #dynamic used for?
4) Can I completely forgo the use of #synthesize or is there a good use case for it?
Upvote and down vote as you see fit.
There's a lot to answer here. I'll break it down:
Declaring ivars
As you've correctly noted, modern versions of the compiler will synthesize backing instance variables for declared #properties. The exception to this is on 32-bit Macs, where the modern Objective-C runtime, including non-fragile instance variables, is not available. Assuming your application is not targeting 32-bit OS X, you don't need to explicitly declare the backing ivar for an #property.
If you still want to use an ivar directly, without a corresponding #property (something I consider a bad idea most of the time), you of course must still explicitly declare the ivar.
#dynamic
#dynamic is as you've said meant to tell the compiler "don't synthesize accessors for this property, I'll do it myself at runtime". It's not used all that often. One place it is used is in NSManagedObject subclasses, where if you declare a modeled property in the header, you don't want to compiler to complain that there's no implementation of accessors for that property, nor do you want it to generate accessors itself. NSManagedObject generates accessors for modeled properties at runtime. The story is similar for custom CALayer subclasses.
#synthesize
#synthesize explicitly tells the compiler to synthesize accessor methods, and (on iOS and 64-bit Mac) a corresponding ivar for the specified property. There are three main cases where you still need to use it:
32-bit Mac apps.
If you've written your own custom setter and getter (or just getter for readonly properties). In this case, the compiler won't synthesize accessors because it sees yours. However, it also won't synthesize the backing ivar. So, you must use #synthesize someProperty = _someProperty;, to tell the compiler to synthesize an ivar. It still won't synthesize accessor methods of course. Alternatively, you can explicitly declare a backing ivar. I favor using #synthesize in this case.
If you want to use a different name for the property's backing ivar than the default (property name with an added underscore prefix). This is rare. The main case I can think of for using it is when transitioning existing, older code, that includes direct ivar access and where the ivars are not underscore-prefixed.
Best current practice seems to be to use properties for all ivars placing the property either in the .h file if they are to be exposed and in the .m file in a class extension if local to the class.
No #synthesize is needed unless the ivar needs to be different than the underscore prepended property name.
Yes, #dynamic is as you describe.
Further, it is no longer necessary to declare local instance methods or order such that the method is above the use.
First off, #synthesize is gone for these scenarios: do not have to do it any more.
Secondly, you don't need the private ivar anymore either.
So in essence, you can just do properties.
The way of controlling access is the same idiom that had become popular before MOC dropped: put the property in the public interface as readonly and then make a readwrite version in the private interface (which should be, as you show above, merely the name with open and close parens).
Note also, that many of the things that cluttered up the public interface in the past can now ONLY be in the private interface, so for instance IBOutlets, etc., since the controller is going to be the only thing diddling them.
I never see #dynamic used anywhere except in CoreDate-generated entities.
For someone who first worked with C++ where the dream was always that the header/interface merely show the user of the class what they needed and all other details would be hidden, I think MOC (Modern Objective C) is a dream come true.
BTW, highly recommend the intro session from WWDC Modern Objective C (from 2012) and the one this year was great too.
So in the guidelines it says:
For code that will run on iOS only, use of automatically synthesized instance variables is preferred.
When synthesizing the instance variable, use #synthesize var = var_; as this prevents accidentally calling var = blah; when self.var = blah; is intended.
// Header file
#interface Foo : NSObject
// A guy walks into a bar.
#property(nonatomic, copy) NSString *bar;
#end
// Implementation file
#interface Foo ()
#property(nonatomic, retain) NSArray *baz;
#end
#implementation Foo
#synthesize bar = bar_;
#synthesize baz = baz_;
#end
Question is, does this apply to public variables only or private too? It's not really clear on the documentation, but would like to have some thoughts or perspective on why "if" this is only for public or private only? I think that it just makes sense for all public/private so that you don't mess up ivars and using the property
I don't think it particularly matters whether the variables in question are public or private. The practice of synthesizing under a different name makes it explicit when you are accessing the variable directly instead of using the generated accessor method.
Perhaps there's a different question underlying what you're asking: should I typically access private ivars via the accessor or directly? I think most skilled iOS devs tend to use accessors unless there is some particular reason not to (performance, avoiding side effects like KVO, etc.). Doing so is more future-proof and allows for flexibility in the underlying implementation. In a very small way, you're coding to an interface rather than an implementation.
It also might be worth pointing out that the default behavior of Clang is going to change in the future so that property-backing ivars are synthesized named _foo by default. Clearly the powers-that-be consider consider underscoring ivars to be a best-practice.
I am pretty sure much of it comes down to personal preferences, so here are mine, for what they are worth:
I like to distinguish between public properties and "private" instance vars.
Properties are always accessed through their accessors, except for initialization (and within a manually created accessor method, for obvious reasons). Hence, the underscore in the backing ivar is useful, and not really an issue in my daily use of the properties.
Instance vars are used to hold state that is used internally in the methods, but not (directly) by other classes.
I have become very fond of declaring my instance variables in the .m file. Nice, clean and easy (no switching back and forth between .h and .m to declare ivars).
I find that this distinction helps me clear my mind and determine if a property is something outside agents should get and/or set directly (a property in .h), or if it is really just a help to get my method implementations to work (an ivar in .m).
I'd agree with Paul.s. that consistency is your friend, but to me, distinction is a friend, too.
I have several years of experience in Obj-c and Cocoa, but am just now getting back into it and the advances of Obj-C 2.0 etc.
I'm trying to get my head around the modern runtime and declaring properties, etc. One thing that confuses me a bit is the ability in the modern runtime to have the iVars created implicitly. And of course this implies that in your code you should always be using self.property to access the value.
However, in init* and dealloc(assuming you're not using GC) methods we should be using the iVar directly (in the current runtime).
So questions are:
Should we use property accessors in init* and dealloc with Modern Runtime?
If so, why is this different? Is it just because the compiler can't see the iVar?
If I need to override an accessor, can I still access that iVar that will be defined at runtime or do I have to define an actual iVar that the runtime will then use?
Again, if I can access the synthesized iVar, why can't I continue to do this for the init* and dealloc methods?
I read the docs several times, but they seemed a bit vague about all of this and I want to be sure that I understand it well in order to decide how I want to continue coding.
Hope that my questions are clear.
Quick summary of testing:
If you don't declare the ivar in legacy, compiler is completely unhappy
If you use #ifndef __OBJC2__ around ivar in legacy compiler is happy and you can use both ivar directly and as property
In modern runtime, you can leave the ivar undefined and access as property
In modern runtime, trying to access ivar directly without declaration gives error during compile
#private declaration of ivar, of course, allows direct access to ivar, in both legacy and modern
Doesn't really give a clean way to go forward right now does it?
In the current (OS X 10.5/GCC 4.0.1) compiler, you cannot directly access the runtime-synthesized ivars. Greg Parker, one of the OS X runtime engineers put it this way on the cocoa-dev list (March 12, 2009):
You can't in the current compiler. A
future compiler should fix that. Use
explicit #private ivars in the
meantime. An #private ivar should not
be considered part of the contract -
that's what #private means, enforced
by compiler warnings and linker
errors.
And why isn't there a way to
explicitly declare instance variables
in the .m file for the new runtime?
Three reasons: (1) there are some
non-trivial design details to work
out, (2) compiler-engineer-hours are
limited, and (3) #private ivars are
generally good enough.
So, for now you must use dot-notation to access properties, even in init and dealloc. This goes against the best practice of using ivars directly in these cases, but there's no way around it. I find that the ease of using runtime-synthesized ivars (and the performance benefits) outweigh this in most cases. Where you do need to access the ivar directly, you can use a #private ivar as Greg Parker suggests (there's nothing that prevents you from mixing explicitly declared and runtime-synthesized ivars).
Update With OS X 10.6, the 64-bit runtime does allow direct access to the synthesized ivars via self->ivar.
Since instance variables themselves can only be synthesized in the modern runtime (and must be declared in the #interface under 32-bit or pre-Leopard), it's safest / most portable to also declare the ivar
Should we use property accessors in init* and dealloc with Modern Runtime?
My rule of thumb is "possibly" for -init*, and "usually not" for -dealloc.
When initializing an object, you want to make sure to properly copy/retain values for ivars. Unless the property's setter has some side effect that makes it inappropriate for initialization, definitely reuse the abstraction the property provides.
When deallocating an object, you want to release any ivar objects, but not store new ones. An easy way to do this is to set the property to nil (myObject.myIvar = nil), which basically calls [myObject setMyIvar:nil]. Since messages to nil are ignored, there is no danger in this. However, it's overkill when [myIvar release]; is usually all you need. In general, don't use the property (or directly, the setter) in situations where deallocation should behave differently than setting the variable.
I can understand eJames' argument against using property accessors in init/dealloc at all, but the flipside is that if you change the property behavior (for example, change from retain to copy, or just assign without retaining) and don't use it in init, or vice versa, the behavior can get out of sync too. If initializing and modifying an ivar should act the same, use the property accessor for both.
If so, why is this different? Is it just because the compiler can't see the ivar?
The modern runtime deals with class size and layout more intelligently, which is why you can change the layout of ivars without having to recompile subclasses. It is also able to infer the name and type of the ivar you want from the name and type of the corresponding property. The Objective-C 2.0 Runtime Programming Guide has more info, but again, I don't know how deeply the details explained there.
If I need to override an accessor, can I still access that iVar that will be defined at runtime or do I have to define an actual iVar that the runtime will then use?
I haven't tested this, but I believe you're allowed to access the named ivar in code, since it actually does have to be created. I'm not sure whether the compiler will complain, but I would guess that since it will let you synthesize the ivar without complaining, it is also smart enough to know about the synthesized ivar and let you refer to it by name.
Again, if I can access the synthesized iVar, why can't I continue to do this for the init* and dealloc methods?
You should be able to access the property and/or ivar anytime after the instance has been allocated.
There is another SO question with similar information, but it isn't quite a duplicate.
The bottom line, from the Objective-C 2.0 documentation, and quoted from Mark Bessey's answer is as follows:
There are differences in the behavior that depend on the runtime (see also “Runtime Differences”):
For the legacy runtimes, instance variables must already be declared in the #interface block. If an instance variable of the same name and compatible type as the property exists, it is used—otherwise, you get a compiler error.
For the modern runtimes, instance variables are synthesized as needed. If an instance variable of the same name already exists, it is used.
My understanding is as follows:
You should not use property accessors in init* and dealloc methods, for the same reasons that you should not use them in the legacy runtime: It leaves you open to potential errors if you later override the property methods, and end up doing something that shouldn't be done in init* or dealloc.
You should be able to both synthesize the ivar and override the property methods as follows:
#interface SomeClass
{
}
#property (assign) int someProperty;
#end
#implementation SomeClass
#synthesize someProperty; // this will synthesize the ivar
- (int)someProperty { NSLog(#"getter"); return someProperty; }
- (void)setSomeProperty:(int)newValue
{
NSLog(#"setter");
someProperty = newValue;
}
#end
Which leads me to think that you would be able to access the synthesized ivar in your init* and dealloc methods as well. The only gotcha I could think of is that the #synthesize line may have to come before the definitions of your init* and dealloc methods in the source file.
In the end, since having the ivars declared in the interface still works, that is still your safest bet.
I am running into the same problem. The way I am working around not being able to access the synthesized instance variables is the following:
public header
#interface MyObject:NSObject {
}
#property (retain) id instanceVar;
#property (retain) id customizedVar;
#end
private header / implementation
#interface MyObject()
#property (retain) id storedCustomizedVar;
#end
#implementation MyObject
#synthesize instanceVar, storedCustomizedVar;
#dynamic customizedVar;
- customizedVar {
if(!self.storedCustomizedVar) {
id newCustomizedVar;
//... do something
self.storedCustomizedVar= newCustomizedVar;
}
return self.storedCustomizedVar;
}
- (void) setCustomizedVar:aVar {
self.storedCustomizedVar=aVar;
}
#end
It's not that elegant, but at least it keeps my public header file clean.
If you use KVO you need to define customizedVar as dependent key of storedCustomizedVar.
I'm relatively new to Obj-C (but not to programming) and have also been confused by this topic.
The aspect that worries me is that it seems to be relatively easy to inadvertently use the iVar instead of the property. For example writing:
myProp = someObject;
instead of
self.myProp = someObject;
Admittedly this is "user" error, but it's still seems quite easy to do accidentally in some code, and for a retained or atomic property it could presumably lead to problems.
Ideally I'd prefer to be able to get the runtime to apply some pattern to the property name when generating any iVar. E.g. always prefix them with "_".
In practice at the moment I'm doing this manually - explicitly declaring my ivars, and deliberately giving them different names from the properties. I use an old-style 'm' prefix, so if my property is "myProp", my iVar will be "mMyProp". Then I use #synthesize myProp = mMyProp to associate the two.
This is a bit clumsy I admit, and a bit of extra typing, but it seems worth it to me to be able to disambiguate a little bit more clearly in the code. Of course I can still get it wrong and type mMyProp = someObject, but I'm hoping that the 'm' prefix will alert me to my error.
It would feel much nicer if I could just declare the property and let the compiler/runtime do the rest, but when I have lots of code my gut instinct tells me that I'll make mistakes that way if I still have to follow manual rules for init/dealloc.
Of course there are also plenty of other things I can also do wrong...