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

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 ival, float fval)' would contain a method having the 
type signature `(IF)Ljava/lang/String;'.  Gcj remangles this into the link-time

Obj-C, on the other hand, creates a unique descriptor for the name:


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
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:

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