Ivar and property confusion


#1

NOTE: using 2nd edition Chapter 21

I don’t seem to be the first person to be confused by the example in which a NSMutableArray instance variable is declared alongside a NSArray property in BNREmployee.h. Apologies if this has been discussed to death already. Hopefully, this is a nuanced take on the question. For the sake of experimentation, I

  • got rid of the NSMutableArray instance variable
  • changed the property from NSArray to NSMutableArray
  • removed the explicit accessors in the .m file

and everything seemed to work fine.

I did this for the sake of curiosity, because it seemed like the intuitive way to write the code, and I was actually kind of shocked that there were no consequences, not even any compiler warnings. Are there in fact consequences to taking this “lazy” approach in more complex code? Are these topics revisited or elaborated on in further chapters? Up until this point in the book, everything seemed to make lots of sense and was essentially intuitive. This was the only part that felt like, “do it this way because we say so.”

Thanks.


#2

[quote]* got rid of the NSMutableArray instance variable
* changed the property from NSArray to NSMutableArray
* removed the explicit accessors in the .m file

and everything seemed to work fine.[/quote]
In step 2 you have effectively changed the meaning of the property. It is important to remember that there is an important difference between an NSArray object and NSMutableArray object.

This property declaration does not allow the container to be modified:

... @property NSArray *assets; ...
Whereas, this property declaration does allow the container to be modified:

... @property NSMutableArray *assets; ...
Whether a container object should be allowed to be modified by other objects is determined by the requirements of the problem being solved.


#3

Thank you. I understand the difference between NSArray and NSMutableArray. However, my rationale was that the example required assets to be a mutable array because an employee’s assets are intended to be added and removed as needed. Thus, I didn’t see a need for the read-only features of NSArray, and removed all references to it. I’m not suggesting that what I’ve done is more correct. I’m just curious as to why it would be necessary to do it the way the book suggests if it doesn’t impact the desired functionality. If this is explained in a subsequent chapter, then I’ll be patient. Currently, from my newbie perspective, it seems inelegant to have what appears to be excess or redundant or unnecessary declarations.


#4

Hi Memelab,

In my understanding, NSArray is useful when we want to set something that cannot be changed in the future. For example, if I want to make a soccer game, I will specify the boundaries of the fields in (x,y): Point 1 (0,0), Point 2 (0,100), Point 3 (60,0), Point 4 (60,100). These boundaries won’t be changed throughout the game. That soccer field is only a class, and there will be many objects pointing at it and trying to access or set the properties. If we use NSMutableArray, there is a possibility that the other object interacting with it will change the objects inside the array, while with NSArray it’s impossible.