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 {
__tclObject = ReflectObject.newInstance( interp,
this.getClass(), this );
__tclObject.preserve();
} catch ( TclException e ) {
__tclObject = null;
}
}
return( __tclObject );
}
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?
This is, however, a utility method and I don't want to force every single
object that will eventually be added to the system to copy this code simply
to replace the "DbObj.getClass()" with "ExtendedDbObj.getClass()".
I *want* ExtendedDbObj's (and all other classes' derived from DbObj) methods
and fields exposed. Yes, even in the case of C -> D -> E -> F -> G.
Now, given that... what is fatal about this.getClass()? If it simply the
case that the user would have to explicitly use a method signature for
java::call, that's fine with me. If it means that their extension might
break my Tcl code, I see your point and agree... but is it programatically
*fatal*.
Let's say that I do change this.getClass() to DbObj.getClass(). Would this
mean that
% set obj [some-func-to-get-an-extended-object]
java0x8a
% $obj someExtendedFunc
would change to
% set obj [some-func-to-get-an-extended-object]
java0x8a
% set eobj [java::cast ExtendedDbObj $obj]
% $eobj someExtendedFunc
If that's the case, I 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 AM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] Small test case
>
>
> 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
> prevent C.exit()
> > from being callable I should pass in B.getClass()... right? (Would
> > java::cast allow me to cast the object to type C anyway?)
>
> No, you don't ever want to call getClass(), just pass in B.class.
> That will resolve to the java.lang.Class object for the class B
> at compile time. If you have a class that implements an interface
> I, then you would pass in I.class.
>
> > Does the bad stuff happen because non-public methods and fields become
> > exposed? Is there something *fatal* about it though? Does it cause an
> > exception somewhere?
>
> Yup. All the additional fields on the subclass get exposed if you
> call getClass(). This can hose up the automated method resolver
> because your subclass could introduce a new ambigious method signature.
> As soon as I get around to adding an automated field resolver, it
> could break that too :)
>
> > That's what I don't understand. In all my usages of
> > ReflectObject.newInstance() I *want* the most derived class, I
> do not want
> > the class that it extends from.
>
> I doubt that very much. You don't even know what the most derived
> class might be. If someone comes along and extends C later on,
> do you really want that to break your code?
>
> (from the example)
> B -> C
>
> (now lets say I added a few more derived classes)
> C -> D -> E -> F -> G
>
> I could add some overloaded methods in F that
> cause all your method invocations to break.
> Then what would you do?
>
> > I *want* the most derived class
>
> Do you really want G in the above example? I
> suspect that what you mean is that you want
> C instead of B.
>
> If you want B, pass B.class
> If you want C, pass C.class
> Just don't call getClass()
>
> Make sense?
>
> Mo DeJong
> Red Hat Inc
>
> ----------------------------------------------------------------
> The TclJava mailing list is sponsored by Scriptics Corporation.
> To subscribe: send mail to [EMAIL PROTECTED]
> with the word SUBSCRIBE as the subject.
> To unsubscribe: send mail to [EMAIL PROTECTED]
> with the word UNSUBSCRIBE as the subject.
> To send to the list, send email to '[EMAIL PROTECTED]'.
> An archive is available at
> http://www.mail-archive.com/tcljava@scriptics.com
>
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
