Re: NSMenuItem and NSValidatedUserInterfaceItem

[Quentin Mathé]

Le 6 janv. 09 à 12:29, David Chisnall a écrit :

> On 6 Jan 2009, at 11:06, Fred Kiefer wrote:
>
> > To be honest, I don't see any potential use for the protocol  
> > itself. We
> > need to have an abstraction for the menu representation, but this is
> > already there. Why would anybody use menu items that aren't of a
> > subclass of NSMenuItem?

For example, this allows you to write an NSView subclass that can be  
used as a menu item for example. I think that's what they had in mind  
when they added this protocol.
However composition works pretty well too in the NSView case, you  
write a NSMenuItem subclass that points the view. In fact, they  
precisely solved the problem like this in 10.5 by adding -[NSMenuItem  
setView:].
In my case, the class has an API very similar to NSMenuItem, so  
composition would a bit redundant. Hence the protocol was a  
potentially interesting approach that avoids a cast as discussed  
below. Yet I'm not sure adopting the protocol is the best approach,  
mainly because subtle behavior differences may exist between my class  
and NSMenuItem class. I need to take a look at that.

> > This is Objective-C, not C++.  Types are just there as a hint to  
> > help static error checking - there is nothing stopping you passing  
> > something that isn't an NSMenuItem, but acts like one, to something  
> > that expects an NSMenuItem.  My recommendation would be to track  
> > the Apple changes, since it makes porting from Cocoa easier, and  
> > because it makes for people who use the Apple docs as a reference  
> > (e.g. me).
>
> If we want to use something that isn't an NSMenuItem in future, we  
> just need an explicit cast and to make sure we implement all of the  
> public methods of NSMenuItem (which we'd need to do anyway with the  
> protocol).

Sure, but I just wanted to avoid this explicit cast, that's one the  
reason behind this protocol.

If the protocol is removed, it's just a potential minor inconveniency,  
so I won't object much more than that.

Quentin.