[11] in java-interest
Re: Why is Java not more reflective?
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Fri Apr 21 17:03:02 1995
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: java-interest@java.Eng.Sun.COM
Date: Fri, 21 Apr 1995 13:28:27 -0800 (PDT)
Hi Charles,
Thanks for the feedback.
> To the Java design team:
>
> I am assuming from the above (and from the complete lack of "reflective"
> features being mentioned in the Java language spec.) that one cannot call
> an explicit Java method at runtime. Given that the runtime already has
> the necessary method dictionaries and class structures, I was wondering
> why this restriction was made. [I can think of several reasons myself, but
> I'd like to know your rationale(s).]
The most important reason for not having more reflective features is that
they impact performance and security. We really want to be able to compile
everything into native machine code.
> Also, how does one "work around" the following needs in Java:
>
> (1) A method wants to call upon several others objects to aid it in jobs that
> require callbacks back into itself; if it wants to have several simultaneous
> callbacks outstanding, using the same name for the callback methods involves
> discriminating the sender at runtime (clumsy and annoying). Without the
> anonymous methods of Lisp or the "perform:" message in Smalltalk, how does
> one achieve a similar result?
We use to have a dynamic dispatch object. It does not have to be part of
the language to make this possible. You can build a dynamicly linked library
that will allow you to call arbitraty methods in objects dynamicaly given the
primitive method invokation functions which are provided by the interpreter.
It would be relatively expensive and you have to be careful about security..
> (2) Even more disturbing is trying to use delegation of various kinds. The
> simplest problem is trying to re-send a message to a different receiver after
> catching a NoSuchMethod exception (useful for implementing unusual but very
> flexible object models or for "standing in" for another object and then
> passing along all the messages you don't understand to it).
I believe delegation can be done without language tricks. Aren't you better of
generating some code to do the delegation for you?
> (3) Finally, what about sending an arbitrary message to an Array of objects?
> Without "perform:" you have to explicitly loop each time and send it by hand.
> Is there a better way to implement this (and even more complex control and
> iteration paradigms)?
Java supports the notion of interfaces. If you have an array of Printable
objects (ie objects that implement the Printable interface) then you can
print them, regardles of their actual type.
> One simple thought exercise shows a case where reflective features are quite
> nice: you have an interactive environment that displays objects visually.
> When selected, you can type in a simple message to send to the object. Even
> being able to enumerate message names and providing a list of "understood"
> messages would be better than nothing in this case, but even that is not
> possible within the current paradigm, correct?
>
> Are you simply thinking that all such "complex" Java environments will have
> to include the full compiler?
All environments can include a compiler, but it is not necessary. The compiler
is relatively heavy weight. Java is not intended as a scripting language. If you
want dynamic behaviour, then you should use our Tcl interface.
> I'd like as many Java people to respond as have the time, for a feel the spec.
> does not express the intentions and goals for the language as well as it might,
> and I'd like to get a better sense of them from you.
The intentions of the language are to be simple and expressive without
adding the kitchen sink. There are many really useful features that could
be added to Java in the long term, some of which will have a great impact
on performance, memory use and security. My personal favorite is parameterized
types, which could solve a lot of your problems. Maybe one day that will
happen, we don't want to create another C++ though.
Have fun,
Arthur van Hoff
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
