The bigger problem is that the line:
a = [[a select] hasPrefix:@"a"];
gives
assignment makes pointer from integer without a cast
In this case, hasPrefix normally returns a BOOL, but I'm expecting
an NSArray*. Internally the code deals with this and does the
right thing, but I can't see a way to trick the compiler into not
giving a warning of some description.
So if you have [a select] returning id, then I think the type
checker matches up hasPrefix: with the specific hasPrefix: in
NSString, because no other method with this name exists. However if
you return a specific type, then it will match up with another
object. So if you have [a select] return an FakeObject*, and
FakeObject* has a hasPrefix: defined that returns type id, then I
would think that the type checker would no longer complain. However
you will get a warning saying the object might not respond to the
message if you don't declare all of the methods you can possibly
call in FakeObject.
I was ready to dismiss this suggestion on the basis that it just
changes the warning, and I'd previously tried it and discarded it for
that reason, but it got me thinking...
The thing about a "FakeObject may not respond to method hasPrefix:"
warning is that it's easily solvable with a category on FakeObject:
So effectively this requires a little extra bit of code tucked away
in a header file, in order to keep the actual select call as clean as
possible. I think that's a reasonable trade off, especially given it
makes everything nice and type-safe.
I'm going to go with this solution for now. Thanks for getting me
thinking, Robert. :)
Cheers,
Pete Yandell
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
