Re: [Pyobjc-dev] exception handling design pattern

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

On Wednesday, Oct 16, 2002, at 16:27 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Wednesday, October 16, 2002, at 02:42 AM, Ronald Oussoren wrote:
>> On Tuesday, Oct 15, 2002, at 23:53 Europe/Amsterdam, Bill Bumgarner 
>> wrote:
>>> Looking at the implementation, it looks like the problem lies in the 
>>> behavior of the ObjC->Python part of the bridge in that it leaves 
>>> the NSException in a wrapped up state?
>> That's right. I never got around to implement this, adding this code 
>> should be relatively straightforward. I'll look into it.
>
> Thanks.   It isn't a huge issue, but anything that makes the bridge 
> more transparent is definitely a boon.
I've just checked in a fix. Forwarding exceptions in the 'other' 
runtime is now cleaner, and when the exception travels back into its 
own runtime it regains its original identity.

There is one thing I have not really looked into yet: What is the 
normal way of processing exceptions in Objective-C, do you use '==' or 
'isEqual' to check if the exception is one you can handle? If it is the 
former some additional work is necessary: NSString objects are 
transparently translated into Python strings and Python strings are 
translated in (freshly allocated) NSStrings. Thus when you trow 
NSSomeException from Python it is 'isEqual' on the Objective-C side but 
not '=='.

> BTW:  The bridge is working *really* well.  I'm using it in a 
> production development setting and have had 0 problems other than of 
> my own making (the exception issue wasn't a big deal).
Wow, I can debug without a real testsuite :-)

>
>> BTW. I've been playing with libffi and I'm pretty sure it can be used 
>> to remove the need for the register.m file. I already have a function 
>> that returns an 'IMP' for in the Objective-C method dispatch table 
>> (given a method signature). I can't test this at the moment because 
>> libffi refused to build into a shared library...
>
> If the inclusion of a shared library requires end users of standalone 
> applications to go through some kind of installation process to have 
> the shlib dumped off in the proper location, I will be very strongly 
> against the inclusion of features that require a shared library.

I agree, if I get this into a usable shape libffi should be linked into 
the objc._objc module (no seperate shared library). An external library 
should also never be required for using PyObjC, we should keep the 
current mechanism.

The problem I'm currently having is that one of the source files won't 
compile into an object file that can be used in a dynamicly loaded 
object.
>
> The value of the PyObjC bridge is primarily that it can be used so 
> transparently within the X environment.    At this point, the PyObJC 
> is considerably more straightforward to use than the Java-ObjC bridge 
> and is easier to use than the AppleScript Studio bridge.
>
> Anything that takes away from that transparency must have a huge 
> return on investment to be worth it.
>
<nod>

> With all that said, eliminating the register.m based dispatch would 
> certainly be a win.   Did you receive my earlier message regarding 
> method dispatch within the Java<->ObjC bridge?   It was able to do its 
> thing without requiring a mapping for every method and without 
> something like the register.m functionality.

I did receive you earlier message, but didn't use that information at 
the time.

The description in your mail sounds a bit like OC_PythonObject in 
PyObjC, but not quite. You wouldn't have a pointer to more information, 
would you?

I ran 'bridget' on '/Developer/Java/Jobs/Foundation.jobs' and looked at 
the results. This tool generates java classes with lots of 'native' 
methods. The implementation of these methods call into Objective-C 
using objc_msgSendSuper (like the super_N functions in register.m). At 
least this explains why you can do 'super.method()' in subclasses of 
Java proxies.

 From what I see in the header files, message passing from Objective-C 
to Java is  done through an NSProxy-style class, like you already wrote.

This is a bit like I expected. The problem with 'objc_msgSendSuper' is 
that there is no version of it that accepts a 'va_list' type argument 
(like objc_msgSendv) which means you can only generate calls to 
objc_msgSendSuper by manually building a stack-frame (or by using a 
library that does this for you).

BTW. Whoever wrote bridget is quite fond of CPP, making sense of the 
layers of macros was quite an adventure :-)

Ronald