Objective-C vs. gcj (was: Re: Newbie questions)
Jon Olson
olson@mmsi.com
Sat Apr 1 00:00:00 GMT 2000
On Thu, 13 Jan 2000, Maury Markowitz wrote:
>> with GCC in the gcc/objc directory) and is useless without it. It
>> handles all the method dispatching and dynamic binding required by the
>> Obj-C language.
>
> Right. That method dispatching and dynamic binding is rather
>similar to Obj-C's though, and not by coincidence.
>
Java actually has binding semantics much more akin to C++ than
Obj-C. In addition to the relative unpopularity of Obj-C, C++ was
a much better choice for the CNI interface than Obj-C would have been.
Java doesn't do dynamic binding like does Obj-C, but rather performs
run-time checking of downcasts.
In Obj-C, all bindings are made at run-time via signatures generated
by the compiler. This is because Obj-C allows a method to be dispatched
on an `id' without any compile time knowledge of whether or not that object
actually implements that method. Thus, at run-time each object references
its class metadata via an `isa' pointer, and each class references some sort
of hash table or sparse array as in the following diagram:
Superclass metadata
^
----------- isa |
| Obj-C object | ----> Class metadata ---> run-time hash-table
-----------
C++ and Java, on the other hand, are strongly typed and only dispatch
methods to objects known to actually have the method. Their run-time
representation is typically much different:
------------- vtable
| C++/Java object | ----> Method Dispatch Table
------------- |
v
Class metadata, if it exists
In C++ and Java, method dispatch (except for interfaces) is performed based
on indices unique only to the class being dispatched; in Obj-C, method dispatch
must be performed on selectors which are GLOBALLY unique. Because of Obj-C's
radically different binding semantics, it would be a poor language for
implementing any sort of compile-time binding.
--
Jon Olson, Modular Mining Systems
3289 E. Hemisphere Loop
Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790
More information about the Java
mailing list