Re: [Pyobjc-dev] Functions in the Objective-C method table

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

In the context of going from Obj-C -> Java, there was both the formal 
bridget mechanism, but the ObjC->Java bridge also allowed for arbitrary 
messaging into Java for methods that had not been explicitly bridged in 
a jobs file.   This was done dynamically and, as such, there must be a 
mechanism available that avoids the use of a mechanism like the whole 
"register.m" thing.

In general, the presence of register.m is fairly inoffensive in 
everything but the compilation time -- it is a whole lot faster to do 
the dispatch via the stuff in register.m than it is to do something 
dynamic/on-the-fly.   Why not add the compiled result of register.m to 
the CVS repository as register.o (or as a library) that everything can 
link against -- the only time it would be recompiled is when the 
register.m file is regenerated.

In any case, the Java Bridge-- as of WebObjects 4.5-- works by creating 
an ObjC class for each bridged Java class.  This includes creating both 
a class struct and a meta class struct to describe the Java class in 
terms of ObjC.

The bridged classes do not bridge the instance variables, but do bridge 
each instance and class/static method.

The method signatures were generated on the fly based on the Java 
class's method signatures.   The bridged classes would also 
conditionally have a series of standard methods added to them;  i.e. 
-copy, -retain, -description, etc... depending on the nature of the 
class being bridged (does it inherit from ObjC or Java, etc).

An implementaton of -forward:: or -forwardInvocation: (because it had 
to work with both) was provided to do the forwarding of method 
invocations from ObjC into Java.  This was done by effectively wrapping 
the instance of the Java object in a proxy class (NSJavaObject) that 
contained the appropriate forwarding mechanism.

The forwarding mechanism basically ripped apart the stack by hand, 
converted the arguments to the corresponding Java types based on their 
ObjC signatures, invoked the Java method, then converted the return 
values, as needed.

I could dig some more and see if I can find my notes that may provide 
more detail -- the above was done from memory.   I have some deep scars 
from having to debug some truly painful interaction between ObjC and 
Java under WO 3.5 - 4.5.   There were some nasty bugs that could 
potentially cause a deadlock in the bridge...

b.bum

On Tuesday, October 8, 2002, at 09:06 AM, Ronald Oussoren wrote:

>
> On Tuesday, Oct 8, 2002, at 13:58 Europe/Amsterdam, Jack Jansen wrote:
>> On Wednesday, Sep 25, 2002, at 19:23 Europe/Amsterdam, Ronald 
>> Oussoren wrote:
>>
>>> The major problem I see with the current version of PyObjC is the 
>>> (large) list of functions that are used in the method dispatch 
>>> tables in Objective-C classes (the file 'Modules/objc/register.m'). 
>>> Using a static list makes the compile-time of PyObjC too long and 
>>> makes it necessary to add C module when you want to override methods 
>>> whose signature is not in the table.
>>
>> Is it possible to find out how the ObjC-Java bridge handles this? It 
>> must have the same problems, if I'm not mistaken, and it'll also have 
>> the super method call problem.
>
> I'll take a look at the code generated by bridget, but I wouldn't be 
> surprised if they don't have the same problem because they generate 
> static wrappers.
>
> Ronald
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
In cyberspace, no one can hear you laugh.