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
But let's assume that I do indeed want the most derived class.
I have written a generic database system, for example, which holds objects
of type DbObj. DbObj has a method in it like this:
public TclObject enableTclObject(Interp interp) {
if ( __tclObject == null ) {
try {
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
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
18 matches
Mail list logo
