How inefficient is validateMenuItem?

[Jim Witte]

   I'm reading through Hillegass's Cocoa Programming and am up to the  
bit about menu updating using validateMenuItem.  It seems that using  
validateMenuItem for something that is not likely to change EVERY  
single time the menu is opened would be rather inefficient as opposed  
to simply pulling the Carbon MenuRef from the NSMenu somehow, and  
then using a Carbon function to disable the item.  It might even be  
inefficient for ANY item, no matter how often it's called, and it  
also (in some circumstances) takes the 'menu item disable logic' away  
from the place where the menu item is actually disabled in the code -  
if that makes any sense (I do something that causes the item to have  
no meaning in one place, but don't tell the system to disable it  
until in the validateMenuItem, which is in a completely different  
place perhaps).

   Plus, since the same validateMenuItem routine is called for each  
menu (and possibly more than one menu if you've set it up that way) -  
if there are several items that need to be checked, it's not clear  
how efficient the menu-item check code is going to be (a giganitic  
switch statment on menuItemNumber of whatever..  And if @selector()  
has to convert the NSString *at runtime* to a selector code..  Forget  
it)

   If an individual NSMenuItem could be connected to a specific  
validateMenuItem routine, this might decrease the 'mutliple item  
switch' overhead (although it increases code size, and if routines  
are found at runtime, then..)

   What are the general practices for when to use validateMenuItem  
and when to just use the Carbon functions or..  are there other ways  
to disable items?

Thanks,
Jim Witte