On Oct 12, 2011, at 01:08 , Thomas Clement wrote:
Xcode 4 and llvm was said to improve symbols indexing so with such code:
NSCache *cache = ...
[cache setDelegate:self];
If you ask to jump to definition on the "setDelegate:" method it would jump you to the definition of -[NSCache setDelegate:].
Well actually it does not, instead it displays a menu filled with all the setDelegate: methods gathered from all the frameworks and project. And this happens also all the time with my own methods as well, Xcode displays menus of methods instead of jumping directly to the appropriate method based on the receiver type.
I'm not sure why you think this is a result of deficient *indexing* rather than a design decision. Jump to Definition takes you to the definition of the *selector*, not to the definition of the method being called. So, if there are multiple methods declared with that selector, you get to choose.
In part, the reason it behaves like this is that the editor (and the compiler, for that matter) doesn't strictly know which of the methods is going to be called. At the 'setDelegate:' call, 'cache' might be a subclass of NSCache with its own implementation of that method.
You can certainly argue that defaulting to the "obvious" method would be a better choice, but that would leave a need for a separate function for calling up the menu. I would speculate that the Xcode editor interface is so overloaded with modifier-key variations on basic functions that it was decided to leave out what was thought to be the less essential function, but I'm just guessing.
Also, I realize you may just be using NSCache as an example, but what's the point of jumping to -[NSCache setDelegate:] anyway? You're just going to go to the .h file, which contains no useful information. If in fact your problem is really with jumping to your own methods, then I think the following considerations arise:
1. If the "duplicate" method signatures are unrelated methods in different classes, it might be a better choice to make them unique. There are some dangers in Obj-C using one selector for different (i.e. non-polymorphic) purposes.
2. If the "duplicate" signatures are overrides within a class hierarchy, you can't really expect the editor to choose one for you.
3. If the "duplicate" signatures are in separate classes but intentionally identical (i.e. real polymorphism), then it would probably be reasonable to expect the editor to choose the correct one, wherever the type is known at compile time.
My logic here is imperfect -- you could certainly dispute my reasoning -- but I'm trying to make the point that the issue you raise is deeper than it might seem, and there are multiple competing factors in any possible resolution.
FWIW.