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