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