public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Obj-C wrap-up
@ 2000-04-01  0:00 Maury Markowitz
  2000-04-01  0:00 ` Jeff Sturm
  0 siblings, 1 reply; 3+ messages in thread
From: Maury Markowitz @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

  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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 Obj-C wrap-up Maury Markowitz
2000-04-01  0:00 ` Jeff Sturm
2000-04-01  0:00   ` Jon Olson

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