I was having some trouble with some odd Cocoa Bindings behaviours and
I tracked it down to the getKey method.
According to the docstring:
> The following attributes and accesors are tried (in this order):
> - Accessor 'getKey'
> - Accesoor 'get_key'
> - Accessor or attribute 'key'
> - Accessor or attribute 'isKey'
> - Attribute '_key'
However, the actual order appears to be:
- [if objc object/class] obj.valueForKey_(key)
- [if dict-like object] obj[key]
- [if array-like object] [ getKey(elem, key) for elem in obj ]
- Accessor 'getKey'
- Accessor 'get_key'
- Accessor or attribute 'key'
- Accessor or attribute 'isKey'
- Attribute '_key'
I'm running into problems because I'm trying to use an accessor on an
object that implements __getitem__. With this order, some dict-like
objects will block the ability to use accessors or attributes as
bindings. The problem arises because getKey uses __getitem__(key)
and tries the next method if KeyError is raised. In my case, I'm
using a network proxy; accessing an invalid key indicates to the
proxy that it is out of sync with its networked backing, causing a
SyncError to be raised, which is not caught by getKey.
It seems the resolution order should probably be switched to perform
the dict-like and array-like lookups last, since they are more
implicit than using a named accessor or attribute. I've attached a
patch for these changes. It works for me, but I haven't run it
through the test suite or tested it with the example applications.