Re: [Pyobjc-dev] Cocoa Bindings (was: Re: Default to returning (void)?)

[Marc-Antoine P. <map...@ac...>]

Le 04-02-16, =E0 11:03, b.bum a =E9crit :

> For once, I may have managed to beat Ronald to this.  Let's hope I got=20=

> it right.
...
> def Accessor(func):
>     """
>     Return an Objective-C method object that is conformant with=20
> key-value coding
>     and key-value observing.
>     """
>     argCount =3D func.func_code.co_argcount
>     if argCount is 2:
>         return selector(func, signature=3D"v@:@")
>     elif argCount is 1:
>         return selector(func, signature=3D"@@:")
>     elif argCount is 0:
>         raise ValueError, "Too few arguments to function '%s'.  Cannot=20=

> create selector." % foo.func_name
>     else:
>         raise ValueError, "Too many arguments to function '%s'. =20
> Cannot create selector." % foo.func_name
...
> I added Accessor() to objc.   Accessor is the generic term for the=20
> setters and getters in Key-Value Coding.  The Accessor() function=20
> tries to intelligently determine if it should return the setter or=20
> getter signature.   I can see two problems with that:
> On the 'performance hack' front, supporting indexed accessors in an=20
> automated fashion would also be useful, but I haven't thought about=20
> how useful that might truly be or what implementation pattern should=20=

> be used.

Se were you planning to have an indexedAccessor as a separate function=20=

type?
Because from what I read, the indexed key-value accessor methods are a=20=

bit more complex, and one cannot rely on signatures alone:

getters:
	Core:
		-(uint)countOf<Key>
		-(id)objectIn<Key>AtIndex:
	Optional:
		-(id[])get<Key>:(uint)range:(uint)
setters:
	Core:
		-(void)insertObject:(id)in<Key>AtIndex: (uint)
		-(void)removeObjectFrom<Key>AtIndex:(uint)
	Optional:
		-(void)replaceObjectIn<Key>AtIndex:(uint)withObject:(id)

So what do we do now, if we implement all of these in a Python class?
Python argcount is obviously not the answer. The options I see are
1) introduce so many method types (indexedGetter, indexedInsert,=20
indexedCounter...)
2) Rely on name structures using the same conventions as objective-C
3) assume that any python collection will be handled by an attribute=20
slot

It is made all the more complicated by the fact that the to-many=20
relationships in ObjC can have meta-information that declares the=20
inverse relationship between to objects. Would you want to go so far?

I suggest we all think carefully about this and other KV coding issues,=20=

as it might impact what ends up being the "best" solution for atomic=20
accessors.

Marc-Antoine