public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jon Olson <olson@mmsi.com>
To: Jeff Sturm <jsturm@sigma6.com>, Maury Markowitz <maury@oaai.com>
Cc: java-discuss@sourceware.cygnus.com
Subject: Re: Obj-C wrap-up
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <00011312435806.12119@toontown.mmsi.com> (raw)
In-Reply-To: <387E2CF0.3A0BBE9A@sigma6.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

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

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-01  0:00 Maury Markowitz
2000-04-01  0:00 ` Jeff Sturm
2000-04-01  0:00   ` Jon Olson [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=00011312435806.12119@toontown.mmsi.com \
    --to=olson@mmsi.com \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=jsturm@sigma6.com \
    --cc=maury@oaai.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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