Thanks for the dialog. Changing o.getClass() to Object.class in my example made no
difference... the
occasional "invalid command name" error still occurred. (In changing an arbitrary Java
Vector to a
Tcl list, there is no other information that justifies identifying a specific class
other than
Object.)
I have abandoned the Java MakeTclList class and replaced it by the following Tcl proc,
which is
functionally equivalent to what I was doing originally with getClass(). That seems to
make the error
go away. So there is still some sort of error in the Java version, or the TclBlend
methods used in
the Java version, that has nothing to do with getClass().
[proc makeTclList {vector} {
set result [list]
if {! [java::isnull $vector]} {
set enum [$vector elements]
while {[$enum hasMoreElements]} {
set data [$enum nextElement]
if {! [java::isnull $data]} {
lappend result [java::cast [[$data getClass] getName] $data]
}
}
}
return $result
}]
Mo DeJong wrote:
> On Thu, 29 Jun 2000, Dr Wes Munsil wrote:
>
> > Mo DeJong wrote:
> >
> > > There is no "compile time" in Tcl, it is all dynamic, ...
> >
> > Exactly my point. Consider these two code snippets, which I assume you agree are
>correct uses
> > of newInstance():
> >
> > B x = new C ();
> > ReflectObject.newInstance (interp, B.class, x);
> >
> > C x = new C ();
> > ReflectObject.newInstance (interp, C.class, x);
> >
> > The _exact same reference value_ is passed to newInstance() as its third argument,
>in each
> > snippet. The only factor that determines the second argument is the type (not
>class) of x,
> > which is a purely compile-time Java notion. It is surprising to me that this
>compile-time Java
> > notion should find its way into the dynamic semantics of Tcl--but I accept that
>you probably
> > have legitimate reasons for doing that.
>
> The same object is passed as the third argument, but two different entries
> in the reflect table are created. One for x referenced as type B and
> one for x referenced as type C. The semantics you describe is how Tcl/Java
> worked in version 1.0. It "seemed" to work most of the time, but there
> would be these edge cases that would break working code. The design
> problem was not easy to correct, it took a long time and required
> introducing a lot of new code (like the java::cast command).
>
> > But--because each snippet is passing the same reference value to newInstance(),
>and because
> > newInstance() has no way of knowing how x was actually declared in the Java
>program text, it
> > still seems to me that either form could be used, AS LONG AS THE USAGE IS
>CONSISTENT, and
> > TclBlend would be happy. In other words, if x is _always_ referred to as a C, and
>_never_ as a
> > B, no harm should result. And the second form is equivalent to
> >
> > C x = new C ();
> > ReflectObject.newInstance (interp, x.getClass (), x);
>
> It depends on how you define "no harm". You will always be able to
> come up with a specific example where nothing goes wrong, but that does
> not mean it should be done that way in general.
>
> As soon as you can access functions in the subclass C that would
> not have been accessible from type B, you increase the chances
> that something could ge really wrong.
>
> For example, this snippet of code:
>
> String s = "Foo";
> ReflectObject.newInstance (interp, s.getClass(), s);
>
> Since java.lang.String is a final class there is no way
> it could have a subclass, so in this one case nothing
> would go wrong. This does not generalize out to all
> classes.
>
> Also, don't forget that calling getClass() means
> that you are unable to use interface types.
>
> 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
----------------------------------------------------------------
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
