On Thu, 29 Jun 2000, Jeff Sturm wrote:
> 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() {
> > S
On Thu, 29 Jun 2000, Jeff Sturm wrote:
> Interesting discussion... it seems as though TclJava tries to enforce
> type safety on Java objects. Other scripting add-ons I've seen and used
> for Java make no such attempt. For example, the default COM bindings on
> the MS VM permit invoking any publ
Interesting discussion... it seems as though TclJava tries to enforce
type safety on Java objects. Other scripting add-ons I've seen and used
for Java make no such attempt. For example, the default COM bindings on
the MS VM permit invoking any public method on a particular object, and
doesn't ha
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:
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
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,
> rig
agree with you completely that from a long-term
perspective it would be better for me to call DbObj.getClass(). Hmmm
sounds like I've convinced myself you're right.
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 29, 2000 8:41 A
On Thu, 29 Jun 2000, Thomas McKay wrote:
> 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 prev
CTED]
> Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Small
> test case
>
>
> On Wed, 28 Jun 2000, Dr Wes Munsil wrote:
>
> > Yes, in Java, I need to know the class of an object in a
> vector, so I can cast it back
> > to that class if I need to
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 (
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.newInstanc
On Wed, 28 Jun 2000, Dr Wes Munsil wrote:
> Perhaps what you mean is that the class passed to ReflectObject.newInstance() must
> identify the _type_ of the _expression_ that is the third argument (sometimes called
>the
> compile-time type), not the _class_ of the _object_ referred to by that exp
On Wed, 28 Jun 2000, Dr Wes Munsil wrote:
> Yes, in Java, I need to know the class of an object in a vector, so I can cast it
>back
> to that class if I need to call any of that class's methods. getClass() tells me
>exactly
> that. So if that is incorrect in TclBlend, there must be something el
Mo DeJong wrote:
> It depends on what you are doing. In regular Java, you need to know
> what the type of the objects you put into a vector are because
> you need to cast them back up to something when you pull them
> out of the vector. TclJava is no different, you just put the
> class you would
On Wed, 28 Jun 2000, Dr Wes Munsil wrote:
> Mo DeJong wrote:
>
> > Objects do not have types, references to objects determine what behavior
> > the object will provide. In Tcl/Java you don't really have a reference
> > but you "reflect" an object as a type. You need to pass in the
> > java.lang.
Mo DeJong wrote:
> Objects do not have types, references to objects determine what behavior
> the object will provide. In Tcl/Java you don't really have a reference
> but you "reflect" an object as a type. You need to pass in the
> java.lang.Class object that a given java.lang.Object will be refl
On Wed, 28 Jun 2000, Dr Wes Munsil wrote:
> I think the implication is that it is simply not safe to do what I have done,
> which is attempt to use a Tcl list to iterate over Java objects. You must use
> Java iteration mechanisms instead (e.g. java.util.Enumeration).
No, that should work just fi
I think the implication is that it is simply not safe to do what I have done,
which is attempt to use a Tcl list to iterate over Java objects. You must use
Java iteration mechanisms instead (e.g. java.util.Enumeration).
Jiang Wu wrote:
> The problem is that the code assumes
>
> set dataList [m
On Tue, 27 Jun 2000, Dr Wes Munsil wrote:
> A question, and a comment.
>
> 1) What does that mean? Objects don't have types: variables have types, objects
> have classes (http://www.javasoft.com/docs/books/jls/html/4.doc.html#24887).
> o.getClass() is the class of the object. I don't mean to be
The problem is that the code assumes
set dataList [makeTclList $content]
sets the variable 'dataList' to the "TclList object" returned by your
MakeTclList command. Suppose that the Tcl interpreter makes a copy of the
list returned by MakeTclList using its string form. Then your original list
A question, and a comment.
1) What does that mean? Objects don't have types: variables have types, objects
have classes (http://www.javasoft.com/docs/books/jls/html/4.doc.html#24887).
o.getClass() is the class of the object. I don't mean to be pedantic, but if
there is really some TclBlend requir
> {
> // We are not supposed to use getClass (); I have never been sure why.
> // In this case, no subclasses are involved anyway, so the result
> // should be the same.
> TclList.append (interp, list, ReflectObject.newInstance (interp,
o.getClass (), o));
>
>
Ack, you should
Here's the test case. There are three files. First I'll tell you what's in them, then
I'll
tell you what's perplexing about the case. Total for the three files is 92 lines of
code.
blah.tcl: the Tcl script that often gets a weird error like 'invalid command name
"java0x3"'.
Four.java: the Java
23 matches
Mail list logo
