Re: [Pyobjc-dev] exception handling design pattern

[Bill B. <bb...@co...>]

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.

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

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

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.

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 really need to dig more deeply into this particular problem.

b.bum