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
