Re: [Pyobjc-dev] Some PyObC tweaks for using EOF and custom frameworks

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

>>  Background:
>>
>>   I'm using EOF 4.5, and I wanted to be able to use python to write  
>> test scripts, mini programs, and scripts that interacted with both  
>> our object model, and shell tools.
>>
>>  Every thing works ok, except I had to make some tweaks.
>
> It's great to hear that PyObjC is still useable with EOF, even after  
> the extensive changes I made to the bridge over the last year.

  Yeah, though EOF doesn't work with 10.2 without some tweaking. :-)
>>

>> import objc
>> import Foundation
>>
>> #VOODOO
>> from Foundation import NSCalendarDate
>> NSCalendarDate.date().description()
>>
>> objc.loadBundle("EOAccess",globals(),bundle_path="/System/Library/ 
>> Frameworks/EOAccess.framework")
>
> This is odd. I'll try to reproduce this with another framework, I  
> don't think we have old WebObjects CD's lying around at the office. I  
> noticed you can download a trial version of WebObjects 5.x, but that  
> seems to be java based.

  Yeah, 5.x is java only.
>
>>
>>
>>  2. EOF does some hackery on the ObjC where objects that haven't yet  
>> been fetched from the database have a fake "isa" pointer. When the  
>> object gets fetched, the isa pointer get reset to that of the real  
>> class.
>>
>>   This crashes on the Python side, but it works if you pre resolve  
>> the fault on the ObjC side.
>
> That doesn't surprise me. Do you know if there is a way to detect this  
> fake isa pointer? Calling  [object self] everytime we want to access  
> an Objective-C object would be way to expensive, especially if this is  
> only needed for WebObjects.

   I dunno, [object self] is really fast for any non-EOF object, and its  
fast for any EOF object that's been fetched already. So its not that  
expensive, and its cheaper then [obj isMemberOfClass: [EOFault class]].  
Its only in pythonify_c_value right now, which has to build new objects  
some portion of the time so it doesn't seem so bad, since building an  
object should take even longer.

>
> I've checked the code and think this may be caused by the call to  
> __pyobjc_PythonObject__ (a few lines below the fragment you included  
> below). From about line 50 in objc_support.m we define a category on  
> NSObject that defines this method. The fake 'isa' obviously doesn't  
> point to a subclass of NSObject. Could you try to change 'NSObject' to  
> 'Object' in the declaration and definition of that category and check  
> if that solves your problem?

  Didn't work, then NO objects saw the category. Perhaps you need some  
special way to add a category to the root object class?
>
> That probably doesn't help with objects that get invalidated. PyObjC  
> doesn't deal gracefully with objects that change their class.

  Yeah, it comes back as a "NoneType" object. after invalidation and  
throws an error.
  probably fixable with another [obj self] call before any method  
dispatching if I can find the place to do it.

Ex:
ec=EOEditingContext.new()
print "fetching"
manager=ec.objectMatchingValue_forKey_entityNamed_("pierce","loginName", 
"MManager")
#portfolio = manager.valueForKeyPath_("portfolio.self");
portfolio=manager.portfolio()
print portfolio.description()
print portfolio.funds().description()
ec.invalidateObject_(manager)
portfolio=manager.portfolio()
print portfolio.description()
print portfolio.funds().description()

Produces:
fetching
<MPortfolio: 0x6bb750>
(Pierce's Fund for Test Crap, MTaco Picks, Value Fund, Bottom Fund)
Traceback (most recent call last):
   File "./pythontest.py", line 37, in ?
     print portfolio.description()
AttributeError: 'NoneType' object has no attribute 'description'

Pierce