You can use the predicateWithBlock: approach that @lxt suggested, or you can use the FUNCTION approach. This would have you build a predicate that looks like this:
[NSPredicate predicateWithFormat:@"FUNCTION(SELF, 'mySuperMethod:', %@)", aParameter];
If you use that predicate to filter an array, then:
SELF will iteratively be each item in the array
- each item in the array will have its
-mySuperMethod: method invoked
-mySuperMethod: will receive aParameter as the parameter to the method
-mySuperMethod: will return a BOOL that has been boxed in an NSNumber << this is very important
- all of the objects that return
YES from -mySuperMethod: will be included in the filtered array.
For more information on this syntax, check out this blog post.
So why might you want to use this approach over the block approach? I can think of two reasons:
- Backwards Compatibility
- If you need this to work on Leopard (blocks on the Mac were introduced in Snow Leopard).
- If you need this to work on iOS pre-4.0 (blocks on iOS were introduced in iOS 4.0).
- You want to serialize the predicate for archival and later retrieval. This is fine as long as
aParameter conforms to the <NSCoding> protocol. Blocks cannot be serialized.
However, if neither of those are requirements, then the block approach will probably be better in the long run, since it's more obvious and readable. :)