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

[Pierce T. W. I. <pi...@tw...>]

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.

>
>>
>> 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.

   Right now,

    object.key

    is interpreted as object.key instead of object.key(). That's the 
worst possible choice, because you want to be able to do

    string.title

    in a KVC binding to get string.title().

  Once you realize that, then the issue becomes whether you want to be 
able to do:

    class.instanceVar

  To pull instanceVar out of a class directly when it has no accessors.

  In that case, it would be confusing if it didn't work, since that 
looks too much like plain python. And in fact, the differences between 
objC and Python don't really matter, because python enforces the rule 
correctly on its side. That is, if someone asks for "a" using KVC you 
can pretty safely assume they really do want a(), because there is no 
self.a.

   The only gotcha would be in the case where you have an instance 
variable that also happens to be callable, but its not a method. I 
think that's kind of an obscure case, but perhaps we could check to see 
if its a bound method of the class?


  Pierce