Obj-C wrap-up

Sat Apr 1 00:00:00 GMT 2000

On 2000年1月13日, Jeff Sturm wrote:
>Maury Markowitz wrote:
>> The main concern revolves around the compiler's generated dispatch
>> tables. gcj makes this as close to possible to C++ in general
>> concept - one of it's goals - which then tosses out the method names
>> (selectors) which would be needed for the dynamic sides of Obj-C.
>>Not quite. Gcj preserves the method names and signatures in the .data
>section. They are needed for reflection, though they are never used for
>ordinary method calls (interface calls in libgcj originally would lookup
>a method by name, but this has been changed to a constant-time lookup).

It's not the method names that are the issue, but the names of the formal
parameters. For example, a Java class file having the method
`String MyClass.foo(int ival, float fval)' would contain a method having the 
type signature `(IF)Ljava/lang/String;'. Gcj remangles this into the link-time
name:
	foo__7MyClassif
Obj-C, on the other hand, creates a unique descriptor for the name:
	foo:ival:fval
In Obj-C, it's possible and common to have two different methods with
the same formal parameter types, but different names for the formal
parameters; in Java/C++, this is impossible. On the other hand, in
Java/C++ it's even more common to define the same method name
but different types for the formal parameters (method/operator overloading);
in Obj-C, this is impossible.
I believe that these differences make Obj-C very difficult to interface
with Java and C++ with regard to method calls. Obviously, they're
easy to glue together using straight C function calls, but making the
object models compatible is difficult to impossible.
-- 
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790