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,
I've been experimenting with integrating tclblend into aolserver, and
after looking at the tclblend code, I'm a little puzzled about
something. In javaCmd.c the variable java declared as type JavaInfo
and currentEnv are declared as global variables, yet I would think
that these two variables
On Thu, 29 Jun 2000, Daniel Wickstrom wrote:
I've been experimenting with integrating tclblend into aolserver, and
after looking at the tclblend code, I'm a little puzzled about
something. In javaCmd.c the variable java declared as type JavaInfo
and currentEnv are declared as global
As you know, Mo, I have also had a tough time figuring out what is *bad*
about passing in obj.getClass().
I can understand if there are methods that you don't want to expose to the
user in the derived class. In your example, if I wanted to prevent C.exit()
from being callable I should pass in
On Thu, 29 Jun 2000, Thomas McKay wrote:
But let's assume that I do indeed want the most derived class.
Seems kind of dangerous, but Ok.
If I change this.getClass() to DbObj.getClass(), then the Tcl objects
returned from this method will only have DbObj's methods and fields exposed,
right?
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo The startup stuff is kind of tricky because we need to support
Mo two different kinds of loading. Tcl Blend can be loaded from
Mo Tcl, whick will then load the JVM. Tcl Blend can also be
Mo loaded from a JVM, this means Tcl Blend
Now don't panic, but it looks like we have uncovered
a serious JVM bug in Sun derived JVMs = 1.2 that
nukes the Tcl/Java reflect table. Lots of
thanks go to Thomas McKay for tracking down and
creating a test case for this bug (it took months).
It looks like two different Java object are
Test ran to completion with Sun's JDK 1.1.8 on Solaris, no errors.
Mo DeJong wrote:
Now don't panic, but it looks like we have uncovered
a serious JVM bug in Sun derived JVMs = 1.2 that
nukes the Tcl/Java reflect table. Lots of
thanks go to Thomas McKay for tracking down and
creating a
Mo DeJong wrote:
Here is another example:
import java.util.Hashtable;
public class Hashtable2 extends Hashtable
{
public static Hashtable get() {
return new Hashtable2();
}
public void NEVER_CALL() {
System.out.println("NEVER_CALL");
}
}
% set h [java::call
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
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
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
11 matches
Mail list logo
