• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: why isn't id<MyCellDelegate> an id?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: why isn't id<MyCellDelegate> an id?
      • From: Jens Alfke <email@hidden>
    • Re: why isn't id<MyCellDelegate> an id?
      • From: Marcel Weiher <email@hidden>
References: 
 >why isn't id<MyCellDelegate> an id? (From: Matt Neuburg <email@hidden>)
 >Re: why isn't id<MyCellDelegate> an id? (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: Can I create a thread with a runloop and a dispatch queue?
  • Next by Date: How to get variably sized header in a UICollectionView supporting both orientations
  • Previous by thread: Re: why isn't id<MyCellDelegate> an id?
  • Next by thread: Re: why isn't id<MyCellDelegate> an id?
  • Index(es):
    • Date
    • Thread