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
22 matches
Mail list logo
