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
