Re: Reflection: setting public fields of an object from another package
Mikhail Teterin wrote:
Eric Sosman wrote:
A further point is that reflection makes the compiler
unable to detect some kinds of errors (e.g., the error that
started this thread), so the problem shows up at run time
instead of at compilation.
A program, that processes run-time supplied data will /always/ be
"unverifiable" at compile time...
Dumbing down programming by banning certain techniques leads to clankier
programs -- which will have more bugs simply by the vice of having more
code.
Did I say anything about "banning?" <checks> No, I didn't.
Which is a Good Thing, because I didn't intend to ban anything
(except Lewish, of course).
Kenneth P. Turvey raised some points about reflection, and
I raised quote a further point endquote, an issue to be weighed
along with all the other pros and cons of using reflection for
some task or other. Engineering is all about assessing these
balances under varying circumstances. If everything had a one-
size-fits-all Right Answer we'd just write the answers down in
an Answer Book and tell the engineers to take up origami.
Reflection is just another tool in the programmer's kit,
to be used or left alone as circumstances suggest. And the
choice to use or not use a particular tool is best made when
the chooser is aware of both its good and bad characteristics.
--
Eric.Sosman@sun.com