How can i check if a variable is an NSArray or an NSMutableArray?
相关问题
- CALayer - backgroundColor flipped?
- Core Data lightweight migration crashes after App
- How can I implement password recovery in an iPhone
- State preservation and restoration strategies with
- “Zero out” sensitive String data in Swift
相关文章
- 现在使用swift开发ios应用好还是swift?
- UITableView dragging distance with UIRefreshContro
- TCC __TCCAccessRequest_block_invoke
- Where does a host app handle NSExtensionContext#co
- xcode 4 garbage collection removed?
- Unable to process app at this time due to a genera
- Swift - hide pickerView after value selected
- How can I add media attachments to my push notific
You have to use:
since a simple comparization of the classes may fail because your array is probably not a NSArray but of some other low level type. You may also check if your array responds to the methods you need.
*Note that the implementation of NS{,Mutable}Array has changed since this answer was written. As a result,
isKindOfClass:
now works. On what platforms where and when, I don't know.Until it is documented as safe to do so, I would strongly recommend NOT writing code that tries to detect whether a collection is mutable or immutable. Even if it were safe, such a design pattern is almost always indicative of a serious design flaw.
(For those with access) Filed rdar://10355515 asking for clarification.
Consider:
(I'm using non-empty arrays because an empty
NSArray
is common enough that Cocoa offers a single shared instance as an optimization.)I.e. neither
-isKindOfClass:
nor checking for implementation ofaddObject:
will work.In short, you can't tell the difference between an NSArray and an NSMutableArray. This is by design and very much the intended behavior. It also holds true for
NSString
,NSDictionary
andNSSet
(all of which have a mutable subclass).That may come as a surprise. The reality, though, is that design patterns that require checking for mutability are confusing to use and incur significant overhead.
For example, if test-for-mutability were a common pattern than all of the methods in Cocoa that return
NSArray
instances would have to actually returnNSArray
instances and never return a reference to the internalNSMutableArray
that might be being used.Bad but technically accurate advice...
The only way to do it is to invoke
[unknownArray addObject:someObject]
inside a@try
/@catch
block and catch theNSInternalInconsistencyException
that will be thrown ifunknownArray
is immutable (the actual exception could be a method not implemented or a class is immutable exception).Good advice...
The short answer though is never try to peer inside an immutable object to see if it is internally mutable.
The reason peering at the mutability of immutable objects is prevented, is to support methods on classes that work like this:
the object
myInternalObjects
could be mutable but this method on this class is saying: don't mutate what I return to you. There may be serious dangers with doing so. If the class allows you to change the array, it will have a different accessor or mutator method.If you have a friend class that needs mutable access to the myInternalObjects variable, then declare a special adapter category that only the friend class imports with a method like
This will allow the friend (which you are assuming is smart enough to not violate special rules) to have the access it needs but without exposing mutability in a broader sense.
If you want a mutable array, make it yourself:
There's very few cases where checking the internal type is a good idea (other answers have already covered those). If you want a mutable array, don't check whether an existing array is mutable, just make your own so that you know it is mutable.
Use ...
[Array isKindOfClass:[NSMutableArray class]]
[Array isKindOfClass:[NSArray class]]
This will work fine.
I would do the following-