Re: [Pyobjc-dev] Objc-agnostic model classes

[Jordan K. <jo...@kr...>]

On 12-Aug-04, at 5:08 PM, Bob Ippolito wrote:

>> 	def personName(self):
>> 		return NSString.stringWithString_(self.pyPerson.personName)
>
> This also isn't necessary, but you should ALWAYS USE UNICODE, or else 
> you can have problems because NSString WILL NOT take arbitrary data.

Understood.  I've changed all the Python class' strings to be u'foo'.  
Had forgotten that part earlier.

>> If this shimming is what it takes, that's fine.. I'm mostly concerned 
>> with how I can reuse the same model classes in Twisted and in PyObjC. 
>>  I do plan on having the model objects contain getters/setters to 
>> make the shim classes easier, but I can't see how to have a pure 
>> Python object support KVC without using objc.accessor or inheriting 
>> from NSObject.
>
> Pure python objects could have KVC if the bridge supported it, which I 
> am +1 on.. but I can't implement this right now and Bill or Ronald may 
> have an objection to it.  Basically I think that KVC on a pure python 
> object should be just regular Python setting and getting.  It may 
> cause problems if the object explicitly inherits from NSObject 
> (because you might want to do something else, or it could get in the 
> way of a superclass' implemention) but for a non-NSObject it should be 
> just what you want 100% of the time.

Agreed.  That would be exactly what I'm looking for.  Maybe once 
decorators kick in and we can define signatures more easily with them, 
I could just define the Python class and auto-build the PyObjc shim 
class from that.  I imagine I'd still want the shim, as it may be 
acting as delegate as well?

>> Ok.  I'll try to think of some other way of doing this for now.  Is 
>> this really hairy stuff, or is there somewhere I should look to try 
>> to help?  I know you've mentioned that you're not sure where the bug 
>> actually lies (Twisted v. PyObjC), but I'll be glad to help however I 
>> can.  Haven't written C in years, but I'm pretty sure I can still 
>> mostly read it :)
>
> It's in Pyrex, and it's not very much code.  It almost definitely has 
> something to do with how using the GIL changed, but I just can't spend 
> a few hours at it right now.

Ok.  Really not my strong point then.  I'll wait :)

J.