Am I missing something? I do not see this behavior in the 8.2.3 Tcl shell:
% proc fern {} {
set x [java::new String foo]
after 10000 "$x toString"
unset x
update
}
% fern
bgerror failed to handle background error.
Original error: invalid command name "java0x1"
Error in bgerror: invalid command name "bgerror"
% proc fern2 {} {
set x [java::new String foo]
after 10000 [list eval $x toString]
unset x
update
}
% fern2
bgerror failed to handle background error.
Original error: invalid command name "java0x2"
Error in bgerror: invalid command name "bgerror"
Jiang Wu wrote:
> This problem may be related to Dr Wes Munsil's problem on "invalid command
> name". Here is the problem script:
>
> set x [java::new String foo]
> after 1000 "$x toString"
> unset x
> update
>
> You will get an error "invalid command name". Comparing that to the script
> below:
>
> set x [java::new String foo]
> after 1000 [list eval $x toString]
> unset x
> update
>
> Your will not get an error. The problem seems to be that Tcl believes that
> a string representation of an object can always be converted back into the
> original object. This is not true in the case of the Java object. The
> first script uses the string form of the Java object to reference the
> object. But that does not increment the ref count of the real object. As a
> result, the later 'unset' call removed the real Java object. Why can't you
> not use "unset x"? Well if this script is inside a proc, then x might be a
> local variable, which will be removed after the proc returns.
>
> The same script rewritten using an explicit list does use the real Java
> object rather than its string form. As a result, the 2nd script works.
>
> I am encountering this problem right now in a different form. I am
> constructing an asynchronous callback function inside Java using a TclList
> object, {command_name java_obj_1 java_obj_2}. The list contains some Java
> objects, which are the arguments to the callback function. However, when
> the callback function is invoked, the function is getting the string
> representation of the argument rather than the real Java objects. This is
> not good because you can't easily find your Java object given a string
> representation.
>
> I wonder if similar problem happens in the C world. But a C object can
> always use a pointer address as its string representation. Then, given the
> string representation, a valid C object can be found.
>
> -- Jiang Wu
> [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
----------------------------------------------------------------
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
