On Thursday, July 02, 2009, at 01:52PM, "Bill Cheeseman" <b...@cheeseman.name> wrote: >On Jul 2, 2009, at 12:24 PM, Keary Suska wrote: > >> Because the two protocols in question are formal protocols, the >> @interface declaration must specify conformance. If it doesn't, then >> no assumption of conformance should be made. Pure and simple. Also, >> protocol conformance is not inheritable in Objective-C. > >1. Taking that last point first, the Objective-C 2.0 Programming >Language document says this: "A class is said to conform to a formal >protocol if it adopts the protocol or inherits from another class that >adopts it." I believe, without checking, that this was true in 1.0, >also. I take that to mean that protocol conformance is in fact >inherited.
You are right on this one. Besides being what one would expect (what I would expect, anyway), sending conformsToProtocol: to the subclass easily confirms it. >Now here's my question for you: In my controller's implementation of - >validateUserInterfaceItem:, I can either limit the items that I enable/ >disable by checking whether their class is NSButton (which I know >responds to -action and -setEnabled:, and I can confirm that >programmatically). Or, instead, I can limit the items by checking >whether they conform to the NSValidatedUserInterfaceItem protocol. If I may chime in (despite the fact that the question was for Keary): as you go on to point out, this brings us right back to "What does it mean to conform?" All the evidence indicates that Cocoa sends a conformsToProtocol: message. Note that NSButton returns NO for this despite implementing the methods in question. This distinction matters because a protocol is slightly more than "a promise that certain methods are implemented" -- it's also a way of stamping a class such that you can ask at runtime, "Does class X have 'Y' stamped on it?" You could have a protocol with no methods for this very purpose. (I feel like there is a common example of this in Cocoa but I can't think of it offhand, so I might be wrong.) To look at it another way: suppose you wanted NSButton to implement -action and -tag methods for some other reason, but *not* be validated by this mechanism. The way to do it would be precisely what Apple's done: go ahead and implement the methods, but don't "stamp" NSButton as an NSValidatedUserInterfaceItem. Getting back to your problem -- I personally would check whether the class is NSButton. Although at first glance I would have rejected this as a kludge, it is not only the simplest solution that achieves your goals and expresses your intent, it is what you would be doing anyway by creating the NSButton subclass. Instead of having code that checks for NSButtons at runtime, you would be manually picking out the instances of NSButton in your nib. >But NSControl does not implement - >setEnabled: Hm, you know what, it seems odd to me that the NSValidatedUserInterfaceItem protocol doesn't include setEnabled: or some such. The doc says, "If no responder returns YES, the item is disabled." But how can the application know it *can* disable the item, much less *how*, unless the item is guaranteed to implement setEnabled:? Bill, although I think you are clearly wrong on some technical points, I agree wholeheartedly that the docs on validation need significant improvement, and I hope anyone else who agrees will file a Radar so it isn't just you and me. --Andy _______________________________________________ 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
