On Thu, 29 Jun 2000, Jiang Wu wrote:

> I just hope people realize that the reflected Java objects in Tcl are not
> the same as any other Tcl objects.  The problem is that these reflected
> objects are presented as "normal Tcl objects".  They are syntactically
> compatible with other Tcl objects.  As a result, they are being used in the
> same way as other "normal Tcl objects".  But the behavior of these are not
> "normal" leading to these seemingly unexplainable bugs.
> 
> If you can explain the similarities and differences between the following
> three lines of code, then you see what I trying to say.  The three lines are
> syntactically identical.

Care to submit some docs patches? We could also use some "Tcl/Java
in action" examples. Nice little examples that do something
cool and show how to use the java::* commands would really
be great. Would anyone be able to help with that?

> > That is not the same thing. A file handle must be closed with 
> > the close
> > command. The close command is like a destructor for an object. Java
> > objects have no destructor, so there is no functional mapping.
> 
> I don't think it matters if Java has destructor or not.  It does matter
> whether the "Java object representation in Tcl" should have destructor.

I was saying that there is no mapping from "close" to a Java
operation (like a destructor).
 
> > A file handle in Tcl is just a hash table mapping from the
> > string name to the file descriptor.
> 
>   A "reflect object" in Tcl is just a hash table mapping from 
>   the string name to the "Java object".  
> 
> The difference is that file handle requires a manual "close", but reflect
> objects can auto destruct at inopportune times.

Well, you can always use your own "lock and unlock" on top of
the existing reflection system. In fact, that is exactly
what the java::lock and java::unlock commands are for.
The only reason they were added was because of this
exact problem.

I think we need to change Tcl to support "locked down"
internal reps to really fix this. Everything else is
just a work around.

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

Reply via email to