Re: why isn't id<MyCellDelegate> an id?
Re: why isn't id<MyCellDelegate> an id?
- Subject: Re: why isn't id<MyCellDelegate> an id?
- From: Tom Davie <email@hidden>
- Date: Fri, 04 Oct 2013 11:30:17 -0700
On 4 Oct 2013, at 10:53, Jens Alfke <email@hidden> wrote:
>
> On Oct 4, 2013, at 9:59 AM, Matt Neuburg <email@hidden> wrote:
>
>> But why is either of those necessary? Surely an id<MyCellDelegate> is, by definition, an id - which inherits from NSObject
>
> ‘id’ is not a type that inherits from NSObject. ‘id’ is explicitly untyped.
>
> ‘id<MyCellDelegate>’ is _not_ untyped — its type is ‘any class that implements MyCellDelegate'. And unless that protocol inherits from the NSObject protocol, it does not include the -respondsToSelector: method.
>
> This may seem inconsistent, but if ‘id<SomeProtocol>’ were really untyped, then you’d lose all type-checking for calls to it, so you could make typos like [cellDelegate foooo:] without any compile-time error.
Right, really the confusion stems from the fact that objective-c has a strange behaviour when dealing with the type “id”. To objective-c “id” means “any object”, and the compiler takes that to mean “I don’t know what it is, so I’m going to assume this all-powerful human knows what they’re doing, and allow them to call any method at all on it.” The more mathematically correct thing to do (and what it does for all other types) is “I don’t know what it is, so I can’t ‘prove’* anything at all about whether this is correct, therefore it’s not correct. Puny human, you must provide me with more information to make proofs”.
Unfortunately, thanks to obj-c’s lack of parametric polymorphism, the “I have no clue what this thing is” situation comes up an awful lot, and it becomes decidedly inconvenient to have that second, more correct behaviour, so I guess someone made a pragmatic decision to effectively disable all checking when ids come up.
My recommendation would be to file a radar about this, along with the fact that ids come up all the time, and show some support for wanting a language where the compiler can make more proofs for us.
Thanks
Tom Davie
* prove is a loaded term when it comes to objective-c, as the runtime can mess up your compile time proof by dynamically switching things about under your feet.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden