Oleg Krupnov wrote:
You are right, casting from alloc worked, thank you.
Is it the recommended practice to always cast after alloc?
Not really - the recommended practice is to have method names which have
unique parameter types. Remember that Objective-C's notion of a selector
is foo:bar:baz:, it doesn't encode what the types of the parameters are
(or the return type). So if you make every foo:bar:baz: have the same
parameter types even though the compiler isn't going to enforce that for
you, life gets simpler. If you have something which is very generic,
like setDelegate: then you could make the parameter an id and test it in
the code.
I have found myself more and more doing methods like this
-(void) methodWithSomeClass:(SomeClass*)someClassArg
anotherClass:(AnotherClass*)anotherClassArg
aSimilarClass:(ASimilarClass*)aSimilarClassArg;
and using the class names in the selector. It's verbose but ..
objective-C seems to be verbose (I wish I could get XCode to fill in a
template for the stuff I defined in the .h file when I go to define it
in the .m file though)
I still have a question in this regard.
If the alloc returns id, then, from the compiler's perspective, there
can be two solutions: 1) assume that the id type can have each and any
method and let it be resolved at run time without any compiler warning
or 2) assume that the id does not have any methods (except NSObject's)
and always issue a compiler warning when there is no explicit casting
to a type. What compiler seems to be doing is rather strange: it looks
through the project, arbitrarily picks up a class with the matching
message name and issues a warning if the rest of the actual message
signature is not matching. How would you explain that?
Well I'd expect the compiler remembers the methods available for each
class, cached under the selector name (remember no argument types in the
selector name). So if you have two identically named selectors in two
different classes but you call them ON instances of that class, all is
fine. For id, the most generic class, I'd expect it caches the first one
it finds with that selector name, then if you use it with different
parameters, it warns you then. It could warn you at the point you
declare the selector with different arguments, but that would be
unecessary, because provided you used it on class instances, not ids,
there's no ambiguity. So warning you at the point you use it on an id
makes most sense.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
