Re: Reflection: setting public fields of an object from another package
Kenneth P. Turvey wrote:
On Thu, 22 May 2008 13:39:44 -0400, Mikhail Teterin wrote:
It always annoys me, that even though the names of the non-private
fields, methods, and classes are /always and very well known at run
time/, accessing them is considered "an advanced technique" -- and even
often discouraged for "impurity"...
Reflection is very powerful and can be used to do things that most
programmers would consider _BAD_. That makes it an advanced technique.
It isn't that it is really that difficult. It just requires more
knowledge to use correctly than most of the rest of the language.
As far as a using it in normal code for public members, there isn't
anything really wrong with this, but it may hide the purpose of the code
from future authors. It tends to add complexity that isn't necessary.
That doesn't mean you shouldn't use it. It just means you should think
about it a bit.
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. Roughly speaking, the longer an
error sits in the code the greater its total cost becomes;
an error caught during compilation is cheaper than one caught
during test, which in turn is cheaper than the one that causes
the customer's CEO to place an irate call to your CEO ...
(Speaking of the cost of bugs, take a look at the stock
price of Moody's Corp since Tuesday, when they went public
about a "computer error." Roughly speaking, investors in MCO
have lost about $3 billion in the last two days.)
--
Eric.Sosman@sun.com