1

The items properties of UIToolbar and UITabBar are designated as copied (copy) properties. 

@property(nonatomic,copy)   NSArray   *items;

But why is this? (copy) won't deep copy the NSArray, so what is the motivation to have these properties shallow copy the NSArray of items?

elasticrat
  • 7,060
  • 5
  • 36
  • 36
  • When you enter your question and the interface shows you possible duplicates and they answer the question, resist the temptation to ask is again. – matt May 16 '13 at 21:04

3 Answers3

2

This is quite standard with NSMutableXXX class cluster members, and you should do the same in your own properties. If you have an NSString property, for example, you should make it copy, not merely strong, lest a client hand you an NSMutableString, keep a reference to it, and mutate it.

copy and mutableCopy are used merely as lightweight ways of switching between NSArray and NSMutableArray, etc.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • And see http://stackoverflow.com/questions/587414/nsstring-property-using-copy-instead-of-retain?rq=1 – matt May 16 '13 at 21:05
1

Because you might assign a mutable array. The copy ensures that if you update the mutable array after assigning it to the toolbar, the toolbar isn't affected.

rmaddy
  • 314,917
  • 42
  • 532
  • 579
1

The point is that they don't want you to change the array behind their back. They don't really want you to change the UIBarButtonItems either. Technically you don't know what the accessor does internally (it could deep copy for all we know) but the property tells you that it will at least copy the array so that if you choose to change the array contents afterwards (assuming it's mutable) then everything will continue to work.

Wain
  • 118,658
  • 15
  • 128
  • 151
  • I can see that. But I still have handles to all the UIToolbarItems in my original array. I suppose some protection is better than none. – elasticrat May 16 '13 at 21:00