Confused on a couple parts!

[b]{
NSMutableArray *_assets;
}

  • (void)addAsset:(BNRAsset *)a;[/b]

How come mutablearray *_assets has to be inside of { and }?

and I just plain don’t understand the method addAsset:(BNRAsset *)a

Any advice would be awesome, thank you so much!

[code]- (void)setAssets:(NSArray *)a
{
_assets = [a mutableCopy];
}

  • (NSArray *)assets{
    return [_assets copy];
    }[/code]

Also confused on these parts with mutableCopy and _assets copy under NSArray.

[quote]How come mutablearray *_assets has to be inside of { and }?
[/quote]
That’s required by the syntactical rules of the Objective-C Programming Language. (All programming languages, just like the natuaral languages, have syntactical rules as part of their grammars.)

[quote]and I just plain don’t understand the method addAsset:(BNRAsset *)a

[code]- (void)setAssets:(NSArray *)a
{
_assets = [a mutableCopy];
}

  • (NSArray *)assets{
    return [_assets copy];
    }[/code]
    [/quote]
    The first method is making a private copy of the incoming object. This is to ensure that the two objects remain independent of each other (that is, changing one does not affect the other.) Making a mutable copy means that the resulting object can be modified.

The second method is giving away a copy of the private object, thereby making sure that the two objects remain independent of each other.

The question that bothers me all the time: why? These two arrays are copying each other’s states for both getter and setter methods, and that effectively eliminates the whole sense of the trick. I don’t understand a logic behind this manipulation. What could possibly go wrong if the mutable array were directly accessible without the unmutable?

The question that bothers me all the time: why? These two arrays are copying each other’s states for both getter and setter methods, and that effectively eliminates the whole sense of the trick. I don’t understand a logic behind this manipulation. What could possibly go wrong if the mutable array were directly accessible without the unmutable?[/quote]

In THIS example it doesn’t matter. But in a different, more complex project it easily could. You could call a method inside Object1 with Object2 as a parameter. Then later you change Object2. If you aren’t copying, that could/would change the state of Object1. So Object1 could have multiple states depending on what something that’s not currently interacting with Object1 is doing.

Imagine if you bought something and instead of getting a copy of the receipt you got a pointer to the receipt that the store keeps (it’s in drawer 5, file 17). And then a day later the store destroys the receipt. Now YOU no longer have a receipt and there’s no record that you bought anything.

I may have the terminology wrong (the terminology seems to be the hardest part for me) but that’s the gist of it.