public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Maury Markowitz <maury@oaai.com>
To: java-discuss@sourceware.cygnus.com
Subject: Obj-C wrap-up
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <200001131830.NAA08363@ns1.oaai.com> (raw)

  Well first off I'd like to thank everyone involved for your  
excellent comments and explainations.  The end result is that my goal  
does not seem doable in any real fashion.  There turned out to be  
two major issues which make such a task (using gcj that is)  
essentially impossible.

  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.   
Thus there's no simple way to mutate Obj-C objects into Java-like  
objects and still retain the portions of Obj-C that we (on this side)  
find useful.  Once the selector information disappears, things like  
forwarding and the concept of id essentially become impossible.  So  
much for some sort of "easy mutation" of the objects.

  Now it would seem that you could construct a different compiler  
like the one that Glenn talked about - that is a compiler similar in  
general goals as gcj, but aimed at making the resulting Java objects  
look like Obj-C rather than C++/G++. Unfortunately it turns out this  
isn't easy either.

  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

  And at that point I think things get really difficult.  Not  
impossible, but big.  We'd need to modify the Obj-C compiler to save  
out the type information somewhere - that's ok.  Now we have to  
modify the runtime to be able to dispatch methods based on either the  
name or type.  That too might be "fakeable" by simply encoding the  
type name into the selector.  Still, now we need a modified Obj-C, a  
new gcj-like compiler that builds to Obj-C, AND potentially some mods  
to the runtime to support it.  IBM's done this with the VA stuff, so  
it's doable, but, well, that's IBM.

  *sigh*.

  Why is it that no one has any problems defining languages, but no  
one has tried to make a good single runtime?

Maury

             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 [this message]
2000-04-01  0:00 ` Jeff Sturm
2000-04-01  0:00   ` Jon Olson

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=200001131830.NAA08363@ns1.oaai.com \
    --to=maury@oaai.com \
    --cc=java-discuss@sourceware.cygnus.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).