public inbox for
 help / color / mirror / Atom feed
From: Jon Olson <>
To: Maury Markowitz <>, Jeff Sturm <>
Subject: Re: Objective-C vs. gcj (was: Re: Newbie questions)
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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
	-------------		|
				  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
PHONE:     (520)746-9127
FAX:       (520)889-5790

  reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-01  0:00 Maury Markowitz
2000-04-01  0:00 ` Jon Olson [this message]
2000-04-01  0:00 ` Jeff Sturm
  -- strict thread matches above, loose matches on Subject: below --
2000-04-01  0:00 Newbie questions Maury Markowitz
2000-04-01  0:00 ` Tom Tromey
2000-04-01  0:00   ` Objective-C vs. gcj (was: Re: Newbie questions) Jeff Sturm
2000-04-01  0:00     ` Kresten Krab Thorup
2000-04-01  0:00     ` Per Bothner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).