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

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

On Sunday, 10 August, 2003, at 16:34, Pierce T. Wetter III wrote:

>>>  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.
But it is much slower than just using 'object'. I'd prefer to not  
introduce unnecessary method calls.

>  So its not that expensive, and its cheaper then [obj isMemberOfClass:  
> [EOFault class]].

If all 'unvalidated' objects are an instance of EOFault we could try to  
add a category on that class. That would have to be implemented in a  
seperate C module, the code fragment below failed to compile when I  
added this to objc_support.m:

	@class EOFault;
	@interface EOFault (PyObjCSupport)
	-(PyObject*)__pyobjc_PythonObject__;
	@end


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

NSObject doesn't seem to be a subclass of Object, that's why everything  
stopped to work. So much for trying to find a common base class for  
NSObject and 'unvalidated' WebObjects objects.

Ronald