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

* Re: Obj-C wrap-up
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Maury Markowitz; +Cc: java-discuss

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

>   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

Right; Java supports method overloading, Obj-C does not.  Obj-C
programmers tend to adopt a convention for naming methods that take
arguments, sort of like method signatures, but it is enforced by the
programmer and not by the compiler.

Since gcj has no global selector table, you'd have to build one, along
with some scheme for mangling Obj-C method names/types into Java method
signatures.  That's where it gets ugly.

-- 
Jeff Sturm
jsturm@sigma6.com

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

* Re: Obj-C wrap-up
  2000-04-01  0:00 ` Jeff Sturm
@ 2000-04-01  0:00   ` Jon Olson
  0 siblings, 0 replies; 3+ messages in thread
From: Jon Olson @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm, Maury Markowitz; +Cc: java-discuss

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

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