> > I could be wrong on this, but I definitely recall thinking it was a > stupid compiler behavior. > > This is because you didn't declare your protocol as extending the > NSObject protocol. If you do something like this: > > @protocol MyProtocol<NSObject> > > Then you can call all the NSObject stuff without warning.
But my protocol only wanted to define the methods in my protocol - a nice clean Interface definition that's independent of all other definitions. After all, Apple might add some non-optional methods to NSObject (ok, that's unlikely) that all objects implementing my protocol would suddenly fail to compile on. Objects could implement MyProtocol *without* implementing NSObject and still be completely useful functionality. They just couldn't be used by code that has chosen to do *other* things to them as well. To keep the discussion from descending into the foolishly abstract, consider NSCopying as the protocol instead. If I want to let you know that the delegate will be stored in a dictionary, I would define the delegate as id<MyProtocol,NSObject,NSCopying>. Would you seriously think it was a good style to declare @protocol MyProtocol<NSObject,NSCopying> ? In my opinion, this is a case where interface definitions are being specified badly to get around an implementation problem. Sure, the delegate they pass in will *probably* be a subclass of NSObject but its not a given, as far as the compiler is concerned. If it must be, then declare it properly. I don't think people understand that id<NSObject,MyProtocol> specifies a hell of a lot less than NSObject<MyProtocol> - all the categories on class NSObject for a start. _______________________________________________ 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 arch...@mail-archive.com
