On Thu, 29 Jun 2000, Jeff Sturm wrote:
> Interesting discussion... it seems as though TclJava tries to enforce
> type safety on Java objects. Other scripting add-ons I've seen and used
> for Java make no such attempt. For example, the default COM bindings on
> the MS VM permit invoking any public method on a particular object, and
> doesn't have the notion of casts or interfaces.
They probably just avoid doing the type stuff because it is easier
that way. If you don't carry a java.lang.Class around with your
java.lang.Object, there are a whole set of problems that you
can just punt on.
> I've tried to understand what you mean by "new ambiguous method
> signature" and I also dug back into the tcljava archives as far as
> possible... I couldn't find any trace of the original discussion.
Take a look at section 5 of my paper on Tcl/Java from the 98
conference, it provides some detailed examples.
http://www-users.cs.umn.edu/~dejong/tcl/paper.html
> I didn't think an ambiguous method signature was possible within a class
> definition. Or do you mean "ambiguous" only in the context of the
> tcljava resolver? I suppose I should go figure out how the resolver
> works... an example would be nice too, if you have one handy.
Tcl/Java has its own runtime method signature resolver because
Java's reflection API is too lame to include one (it really
should do this sort of thing for me, but that is another story).
It looks like I am also going to have to add a runtime field
resolver too.
You could check out the method resolver tests in:
tests/tcljava/AutomaticSignature.test
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
