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.
It takes a moment to get used to the TclJava scheme of things.
Mo DeJong wrote:
> > Does the bad stuff happen because non-public methods and fields become
> > exposed? Is there something *fatal* about it though? Does it cause an
> > exception somewhere?
>
> Yup. All the additional fields on the subclass get exposed if you
> call getClass(). This can hose up the automated method resolver
> because your subclass could introduce a new ambigious method signature.
> As soon as I get around to adding an automated field resolver, it
> could break that too :)
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.
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.
--
Jeff Sturm
[EMAIL PROTECTED]
----------------------------------------------------------------
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
