Objective-C vs. gcj (was: Re: Newbie questions)

Sat Apr 1 00:00:00 GMT 2000

> 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 

 Exactly.
> 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 
declared
> 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.
Maury