FROM : Graham Cox
DATE : Tue Oct 14 11:52:35 2008
On 14 Oct 2008, at 8:17 pm, Oleg Krupnov wrote:
> You are right, casting from alloc worked, thank you.
>
> Is it the recommended practice to always cast after alloc?
No, I never do it. I never see code that routinely does it either.
> 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?
The compiler uses the first one it finds. What else is it to do, as it
has nothing else to go on, and there's nothing to distinguish the two
methods? It doesn't arbitrarily pick one, though it might seem that
way - it goes with the first it found.
Chris's suggestion of using more descriptive method names is good
advice - your code will not only be more readable to you, it won't
trip up the compiler in this way. The casting that you're doing is not
improving readability *for you*, and anything that doesn't help in
that regard is hindering.
hth,
Graham
DATE : Tue Oct 14 11:52:35 2008
On 14 Oct 2008, at 8:17 pm, Oleg Krupnov wrote:
> You are right, casting from alloc worked, thank you.
>
> Is it the recommended practice to always cast after alloc?
No, I never do it. I never see code that routinely does it either.
> 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?
The compiler uses the first one it finds. What else is it to do, as it
has nothing else to go on, and there's nothing to distinguish the two
methods? It doesn't arbitrarily pick one, though it might seem that
way - it goes with the first it found.
Chris's suggestion of using more descriptive method names is good
advice - your code will not only be more readable to you, it won't
trip up the compiler in this way. The casting that you're doing is not
improving readability *for you*, and anything that doesn't help in
that regard is hindering.
hth,
Graham






Cocoa mail archive

