A class cluster has a façade class, such as NSString. Recall that there are many classes that are actually implemented as class clusters. I guess that explains why my buddy couldn’t figure out whether a dictionary was mutable or immutable. They’re both members of the same class, which is a subclass of NSDictionary (hence the success for the isKindOfClass), but they are definitely not a direct instance of NSDictionary or NSMutableDictionary.
IOS ARE DICTIONARIES MUTABLE CODE
You can find the code for this posting in this gist. The obvious ways to ask “Hey! Are you an NSDictionary or an NSMutableDictionary” just don’t work. I recommend “just copy whatever you’re given, and then use it.”īut that does bring up an interesting question. If you need to muck around with a container after it’s passed in to a call, make a local mutable copy.Ī friend of mine asked me “Hey! Given an NSDictionary pointer, how do I tell if it’s mutable?” After the appropriate look of disapproval (ಠ_ಠ), it turned out he was trying to work around some weird behavior in a library he was using. If you want a mutable container to be passed in so you can fill it with stuff, require it in your API. If you ever have a need, given an arbitrary stuff container, to decide if it’s mutable or not, please reconsider your design. I tend not to worry about things like this until measurement (say with Instruments) shows that it’s an actual problem. The collection can’t change, so there’s no benefit in peeling off a new copy. Also, a copy of an immutable object can just turn into a retain. Rather than looping over every object and inserting it into a new array, the implementation of -copyWithZone can just duplicate its internal data structures. The container objects from Apple do all sorts of tricks to make copies efficient. And then for objects there will be retains happening as they’re added to the new collections. There is a memory allocation for the new object, copying the characters, bytes, or object pointers. “But aren’t copies expensive?” They can be for very large containers. It just tells the compiler to trust you that you know what you’re doing. Remember that a cast from one object type to another in Objective-C doesn’t actually change anything. If someone tries to cast the return value to an NSMutableArray and call a mutating method, they’ll get a run time error. Now the _catToys mutable array is safe from the Dog chewing on it. You know that collection will keep on growing, so it makes sense for it to be mutable. Say your Cat object has a list of objects in the house that the cat claims as theirs. Similarly, if you have a mutable stuff container as an implementation detail, be careful about returning it from a method or function. If you just stashed that value away, and then re-used the text field, you’d find your original string value changed. That actually happened in older versions of Cocoa: the string value from a text field would return the mutable string that the text field was displaying. Once you’ve retained the string (or assigned it to a strong reference), anyone with a reference to that mutable string can change it. NSMutableString is a subclass of NSString, so anywhere you can use an NSString, you can use an NSMutableString.
Even though your API may say “Give me an NSString”, someone can create an NSMutableString and give it to you without complaint.
You have to be paranoid when you accept a stuff container that you’ll subsequently to be hanging on to.
All of the sudden, Arthur Dent’s name has changed to Prostetnic Vogon Jeltz. If your object is pointing to a mutable string (say a person’s name), and that string is visible outside of your object, some other unrelated code could change that string. That can make them dangerous to hold on to. You can can alter the stuff at any time without having to create a new container. Mutable stuff containers are very convenient. *** Terminating app due to uncaught exception 'NSInvalidArgumentException' blah blah : unrecognized selector sent to instance 0x1044112c0
0 kommentar(er)
