Re: [Pyobjc-dev] Recent change to K/V coding

[Ronald O. <ous...@ci...>]

On Thursday, 14 August, 2003, at 22:58, Pierce T. Wetter III wrote:

>
> On Thursday, August 14, 2003, at 01:19 PM, Ronald Oussoren wrote:
>
>>
>> On Thursday, 14 August, 2003, at 21:49, b.bum wrote:
>>
>>> The only change I made was the addition of KeyValueCodingMixIn -- a 
>>> class in KeyValueCoding that can be mixed into any pure python class 
>>> to add valueForKey_(), takeValue_forKeyPath_(), etc...    Useful, 
>>> but easy to duplicate, certainly.
>>
>> Why is this useful? If you want to feed the object to an Objective-C 
>> class/method that will use KVC to set/get attributes, the 
>> implementation of OC_PythonObject (which is used to wrap Python 
>> objects when accessed from Objective-C) already contains a full 
>> implementation of KVC.
>>
>> If you want use KVC from Python you can use the functions in 
>> PyObjCTools.KeyValueCoding or subclass from NSObject. In either case 
>> you don't need the mixin. And as I wrote earlier, the methods in the 
>> mixin will *never* be called from Objective-C, which might confuse 
>> users.
>
>   As a long time user of KVC, I can tell you that its useful apart 
> from ObjC. That's why the mix in is good. We should propose it as an 
> addition to Python separate from PyObjC in fact.

There is little change methods like 'takeValue_forKey_' will be 
accepted into the Python core. The KeyValueCoding module has a larger 
change of being accepted. The only difference is the syntax you use to 
access attributes:

	setKey(object, "mykey", 3)

vs.

	object.takeValue_forKey_("mykey", 3)

The former works without a mix in class.

>
>>
>>>
>>> The one change I would like to see-- that I feel is very important-- 
>>> is to fix the callable behavior such that it is inline with 
>>> Objective-C.   The end result should be interchangeable with the 
>>> Objective-C implementation.
>>
>> The current implementation tries to conform to the description of the 
>> default behaviour of the KeyValueCoding protocol. There may be minor 
>> differences due to me not understanding the documentation.
>
>   I think you're just misunderstanding how its applied. KVC's power is 
> that with runtime-bound languages (like Python), you can make 
> arbitrary parameterless method calls from non-code files like say, 
> user interface editing tools.

Your previous message finally made me realize what you and bill are 
trying to say. Sorry for having such a thick scull.

I still think that we should only call instance methods using KVC, not 
the value of instance variables that happen to be callable. BTW. it 
might even be usefull to use __keyname__ as an accessor method for 
reading key keyname, this would make it possible to use KVC to get at 
the length of a string.

Ronald