Re: Obj-C wrap-up

[Jeff Sturm <jsturm at sigma6 dot com>]

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

>   This problem was recently made clear to me by Jon.  The issue here
> is that Obj-C's dispatch is based on selectors, which encode the
> _names_ of both the method and it's parameters.  On the other hand,
> Java encodes the name of the method, but the _types_ of the
> arguments.  I assume this is why Java's multimethods are possible.
> So now you'd also have to change the Obj-C runtime in order to save
> this information in addition to the current selectors

Right; Java supports method overloading, Obj-C does not.  Obj-C
programmers tend to adopt a convention for naming methods that take
arguments, sort of like method signatures, but it is enforced by the
programmer and not by the compiler.

Since gcj has no global selector table, you'd have to build one, along
with some scheme for mangling Obj-C method names/types into Java method
signatures.  That's where it gets ugly.

-- 
Jeff Sturm
jsturm@sigma6.com