On 28 July 2014 04:58, Jonathan S. Shapiro <[email protected]> wrote: > As a two-time debugger author, I guess I don't really see any particular > benefit to reflection for debugging support. What I'm probably not taking > into account is the need to debug dynamically generated code. It isn't > clear to me how important dynamically generating code from the program is > in real life. I wonder if it isn't a case of one kind of dynamic usage > begetting another. I need to understand the pros and cons of that more > clearly. >
I think that the support I would like from the compiler is the support you already require for the GC: A way to walk the stack, a way to determine how the things on the stack relate to your original program, and a way to figure out what the currently executing function is (however they are identified). The mechanisms can be symbols and calling conventions or a big ol Frame object with attributes like f_code and f_lineno. Should these things be exposed to the application, perhaps via a library or a capability? I'm not sure. > > Outside of dumps for bug reports, which are initiated by the runtime and > need not be program accessible, I'm pretty convinced that reflection on > stack frames is a really bad idea. At minimum it's a violation of > encapsulation. > At the very least, ambient authority to look at or manipulate stack frames is probably a bad idea. The optimisation card is overplayed IMAO, a lot of the time you can recreate what would have been the original stack trace even in the presence of inlining. > > I'm *definitely* not sold on reflection for pretty-printing. The compiler > can generate that at compile time in a user-overridable way. > Not sure what you mean by this. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
