I was debugging a maddening bug in a Java program a few days ago where I wished for an uber reflective environment. The bug was in one of my unit tests. It did not occur when I ran the test by itself, but it did occur when the test was run as part of a test suite. I quickly determined that it had something to do with the timing of multi-threaded initialization, but I was stuck beyond that. The way the tests and code had been factored, setting a break point close to where I thought the bug was would break on all the tests, not just the one I was interested in. By getting mildly clever and setting a conditional breakpoint where this.getClass() == BrokenTestCase.class I was able to move a bit closer to the offending piece of code, but still not close enough. I ended up having to break as close as that would get me, manually setting a series of other breakpoints in interesting points and continuing the program. My big fear was the problem was a RaceCondition, and all these breakpoints would keep the bug from showing up. I found myself wishing I could subclass Thread and provide logic that would break on particular message sends or print out a stack trace as it was traversing the code. I really wanted the stack and threads to be first class objects that I could manipulate. The paltry reflection provided by Java was not up to the task. I'm not intimately familiar with it, but I don't think even SmalltalkLanguage provides this level of reflection. (''I got the impression SqueakSmalltalk gets close. -- lb'') I wanted uber reflection! Beyond debugging, certain application tasks could be much simpler and cleaner with uber reflection such as security, transactions, and persistence. --MarkAddleman ----- Mark, RubyLanguage may do something like what you want. You're allowed to add or redefine methods on individual instances, so you could have code that looked like: aThread = Thread.new def aThread.run { Logger.log ("running with safe level" + safe_level) super } ... So you could use that, I think. I'm really finding myself making heavy-duty usage out of Ruby's reflectiveness. I struggled a lot with Java's clunkiness while I was trying to do a quick OR-mapping layer in it; Ruby's easy of reflection (real class methods, runtime method definition) has made this work much much easier for me. -- FrancisHwang ---- I once had a similar problem when dealing with exception handling in Tcl [ToolCommandLanguage]. In my case, I wanted a certain kind of exception to be fatal regardless of any exception handlers up to a certain level of the call stack. I did this by rewriting Tcl's exception handler, sort of. In Tcl a non-local return is intercepted using the 'catch' command, which evaluates an expression and then returns to the caller indicating whether the expression evaluation terminated normally or abnormally. My solution was to use a slave interpreter with a rewritten 'catch' command, that called the 'real' catch command, analyzed the result, and if my condition was met, set a flag that caused all further 'catch' commands to fail with errors. Actually one of my pet peeves about Tcl is that the language syntax consists of 11 rules, and two of them (variable interpolation and comments) have execution syntax that is not accessible from within the language itself. -- ZygoBlaxell Not quite sure what you mean by 'variable interpolation'. Do variable traces ([trace]) allow what you want? --Setok Not sure what he wants with comments either... You can dynamically add a comment to a proc in tcl if you wish to execute a comment. What would you want it to do other than NO-OP? ---- UberReflectiveEnvironments are an interesting idea in general, but I think, that the case describd doesn't really require it. That it, I think, that the unit tests where probably not really of the granularity required for the task under test. On the other hand, if the code tested was in an external/proprietary library, it cannot be helped. In such a case UberReflection might really help. ---- See also: AspectOrientedProgramming, MetaDebugInterface