Re: Obj-C wrap-up

[Jon Olson <olson at mmsi dot com>]

On Thu, 13 Jan 2000, 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