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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev