public inbox for
 help / color / mirror / Atom feed
From: Maury Markowitz <>
To: Jeff Sturm <>
Subject: Re: Objective-C vs. gcj (was: Re: Newbie questions)
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <> (raw)

> with GCC in the gcc/objc directory) and is useless without it.  It 
> handles all the method dispatching and dynamic binding required by the 
> Obj-C language.

  Right.  That method dispatching and dynamic binding is rather  
similar to Obj-C's though, and not by coincidence.

> These two libraries can probably coexist in one address space, but that 
> isn't very useful unless Obj-C code can call Java code, which it can't 


> strongly suspect the answer has mostly to do with the popularity of C++ 
> and relative obscurity of Obj-C, though there may be technical  
issues as
> well.

  And of course the popularity of Java and "impopularity" of Obj-C  
is why I'm here.

> some other language could share the libgcj runtime.  If the Obj-C
> frontend is to have a meaningful existence in the future, it should 
> probably abandon its current runtime and embrace libgcj.

  Right, this is exactly what I am interested in.  Essentially if a  
little bit of API was added to the libgcj runtime I think you'd have  
enough support to also run Obj-C code with the same runtime.  Now you  
have a lib that works on two languages.  This would need some  
changes in the Apple base class, NSObject, but I'd want to do that  
anyway to take advantage of reflection and gc, which is LONG overdue  
in Obj-C anyway.

  But what exactly would this entail?  I'm not a compiler guy  
although my boss is pretty good at this, and is pretty excited by  
these prospects as well.  What I'm trying to fathom is just what  
level of effort would be required.  If I can get a good list of  
"here's the tasks", I can take that and start working.

  A guess right now...

1) Obj-C has a "2nd guess" attempt to deliver messages to objects.   
This is done via a combination of support in Obj-C's runtime and some  
minor support in the root object.  Essentially when a method is  
called on an object it does a lookup in the same way that Java does.  
If that method is not supported the runtime then creates a new object  
(in Obj-C this is an NSInvocation object) and then passes that  
invocation back into the original object, calling "forwardInvocation"  
I believe.  NSObject's default behaviour is to raise a "method not  
supported" exception, but if you override that method you get the  
invocation (which is a wrapper of the name of the method and the  
types of arguments) so you can break it out and do something with it,  
like forward it to another object.

2) Obj-C includes categories.  This would require a new function in  
the runtime to allow function pointers in the method lookup table to  
be replace with new function pointers, and the addition of new  
methods into the dispatch table.

3) Obj-C includes the concept of a "Selector" (type SEL) which is a  
unique string associated with any particular method.  This is used   
to uniquely identify object/message names.

4) Obj-C allows for one object to replace some other.  This would  
require API in the runtime to deal with this.  Essentially it means  
that all calls to "MyObject" simply get forwarded to "MyOtherObject".

5) One missing piece from both runtimes is the ability to re-link  
objects at runtime.  All this means is that you want to be able to  
push a class out and then back in at runtime (Java kinda supports  
this already).  Combined with some support at the IDE level, this  
allows for "link and go", you recompile just that object and keep  
running your app - this makes debugging a lot more fun!

  Changes to the Obj-C compiler would also be needed, to call any  
different API in the runtime, and the Apple object set would likely  
need some updates to support it.  However one thing I would want was  
a re-write of these classes to make sure they are directly callable  
from Java anyway.

> handy.  The Object class differs somewhat from java.lang.Object, but 
> that could be possibly be remedied by making Object a subclass of
> java.lang.Object, or maybe even introduce a new root class.

  Actually for my needs I'd be changing NSObject, although I see the  
benefit here.  I'm curious though, does anyone outside the OS-X  
world actually use Obj-C for deployed apps any more?

> He means Objective-C doesn't do any compile-time binding or even
> checking of method invocations.  Every instance variable can be  
> as "id" which is equivalent to Java's java.lang.Object class.  If a 

  Although this has very practical reasons for existing. It makes  
the creation of interactive GUI editors far easier for instance.

> Note that the Java _language_ is strongly typed though bytecode is 
> not... all names are dynamically resolved from bytecode, just as in 
> Obj-C.

  Which is interesting if you think about it.

> categories.  It's not the same as inheritance, somehow.  Sort of like 
> peer objects, as in java.awt, only more transparent.

  Exactly.  The functionality is doable with Java, but it's simply  
WAY easier and invisible under Obj-C.

> Objective-C has a neat feature which makes it extremely simple to write 
> delegate classes.  The runtime attempts to dispatch a method invocation 
> [snip]
> Similar tricks could be performed with Java reflection, I'd guess. 

  That's interesting.  Ahhh, do you mean that we could use the  
reflection API in the runtime to see if the method is there and then  
re-dispatch?  Hmmm, that might be a "better" (as in leveraging  
existing functionality) solution that Obj-C's in fact.


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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-01  0:00 Maury Markowitz [this message]
2000-04-01  0:00 ` Jon Olson
2000-04-01  0:00 ` Jeff Sturm
2000-04-01  0:00 Newbie questions Maury Markowitz
2000-04-01  0:00 ` Tom Tromey
2000-04-01  0:00   ` Objective-C vs. gcj (was: Re: Newbie questions) Jeff Sturm
2000-04-01  0:00     ` Kresten Krab Thorup
2000-04-01  0:00     ` Per Bothner

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