|
![](/i/fill.gif) |
Darren New wrote:
> My point is that not all uses of reflection are kludgey, and including
> it in a language doesn't mean the design of the language is badly broken.
Oh, and a lot of these language use reflection to implement debuggers,
performance monitors, and unit test frameworks. :-) None of which I'd call
kludges or violations of modularity.
Funny enough, every Python class and method has documentation that's
included in the class (in a member called "__doc__"). There are python test
frameworks that go thru all your classes and members, finding the document
strings, looking for something that looks like the result of running tests
interactively in the doc string, then runs the tests and compares the results.
http://docs.python.org/library/doctest.html
The stuff in the blue strings, with >>> marking the calls (which is the
default python interactive interpreter prompt) gets run by this library,
which then tells you what failed after comparing the results to the
documentation.
In this case, the documentation for the class includes its own simple tests,
which I thought was pretty cool.
Sure, you can do all this sort of stuff with preprocessors generating code,
but that's just because compilers have all the information that reflection
is supposed to make available.
As an aside, there's actually a lack in the terminology. I use the term
"reflection" to mean looking at the source code while it runs, and
"introspection" to mean looking at the process while it runs. So the
question of "what member variables does class XYZ have" is reflection, and
"what's the name of the method two stack frames up from here" is
introspection. Unfortunately, I don't think I've convinced anyone else to
make that distinction. :-)
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |