Difference between using self.varA instead of _varA in Objective C

Question

Possible Duplicate:
Difference between self.ivar and ivar?

I recently had a problem where I was trying to initialize an object, which involved passing in an NSMutableArray for assignment.

I tried doing

- (id)initWithFrame:(CGRect)frame menus:(NSMutableArray *)aMenusArray view:(UIView*)gView
{
    self = [super initWithFrame:frame];
    if (self) {

        // ...some code

        _menusArray = [aMenusArray retain]; // This works
        // _menusArray = aMenusArray; This does not work.
        // self.menusArray = [aMenusArray retain]; This does not work.
        // self.menusArray = aMenusArray; This does not work.

        // ...some code
     }
    return self;
}

"Does not work" means that when I later attempt to treat the array as a NSMutableArray and pass [self.menusArray removeObjectAtIndex:0] or something like that, it doesn't cause an exception with unrecognized selector used on __NSArrayI. In other words, the "does not work" causes the self.menusArray to become an Immutable Array instead of a mutable one.

I was wondering why _menusArray = [aMenusArray retain] works and why the others don't. As far as I knew, property and synthesize simply create accessor methods (the getters and setters). I asked my colleagues, to which they replied I probably have some corrupted memory somewhere.

To be clear, aMenusArray is declared as an NSMutableArray and _menusArray is declared in the header file as follows:

NSMutableArray *_menusArray;

and its properties and synthesize (which is in the implementation) are:

@property (nonatomic, retain) NSMutableArray *menusArray;


@synthesize menusArray = _menusArray;

No, I don't think so. I looked at those. I'm looking for an actual answer as most of those explain that subclassing is when the dot notation is going to cause you trouble. I'm not subclassing so that is irrelevant. Besides proper coding practise + subclassing, there's no other reason not to use the dot notation. That should be enough reason NOT to use dot notation. But - my app crashes if I DO use the dot notation. I've been told this is an indication of corruption somewhere. I need help with pinpointing the corruption. — Mark S, Oct 15 '12 at 19:54
Your question could be a lot more specific, then, starting with what exactly "does not work" means. — jscs, Oct 15 '12 at 20:53
Josh - you downvoted my question and I editted to explain. Apparantly I'm banned from making questions although I really think I'm making an effort to post quality questions on here. Mind lifting that downvote? — Mark S, Oct 19 '12 at 03:08
I don't think you deserve to be question banned. There's got to still be some missing information here, though. Mutable arrays don't just turn immutable. Are you sure you get the _same_ exception later from all three of the "do not work" lines? It's plausible in the first case, since that's an under-retain, and the memory could very well get re-used. I suggest creating a [small, self-contained, compileable example](http://sscce.org/) that demonstrates the problem. Like a unit test, this will help your investigation by elimating confounding factors, and it will definitely help readers here. — jscs, Oct 19 '12 at 18:26

score 1 · Answer 1 · edited May 23 '17 at 12:12

1

Using dot notation with self in your init method leads to unintended behavior. See Initializing a property, dot notation for more details.

edited May 23 '17 at 12:12

Community

1
1

answered Oct 15 '12 at 16:50

Nathan Villaescusa

17,331
4
53
56

So, if we are to use good coding convention, I should never use self. notation in any init methods? – Mark S Oct 15 '12 at 17:26
In my example, can you see why exactly using self.menusArray = aMenusArray; would cause problems? Specifically, this caused the self.menusArray to become an __NSArrayI (Immutable array) even though it was declared as a NSMutable array and aMenusArray was also declared as a NSMutableArray. – Mark S Oct 15 '12 at 17:33
I'm afraid that's beyond my knowledge of Objective-C. – Nathan Villaescusa Oct 15 '12 at 17:35
Alright. I am still actively looking for a solution. While you've shown me some general ideas as to why I should not use self., it seems that advice caters specifically good coding practise and prevents issues from occurring when subclassing - which I am not doing to this object. So I still need to understand what is causing this problem. I am, at the moment, investigating now to use NSZombies. – Mark S Oct 15 '12 at 17:38

Difference between using self.varA instead of _varA in Objective C

1 Answers1