There is a proposal for something similar to this in the EcmaScript 4 Spec. Its optional for ES4 implementations but the semantics could be useful for this discussion:
http://wiki.ecmascript.org/doku.php?id=proposals:stack_inspection The above is based on the Doctoral Thesis of John Clements which is located here: http://www.csc.calpoly.edu/~clements/papers/dissertation.pdf I don't currently have enough time to write up a nickel tour of the ideas in the above docs but maybe this weekend. Kelly On Jan 11, 2008 4:44 AM, Ted Neward <[EMAIL PROTECTED]> wrote: > > Ack, sorry, for some reason in my head StackTraceElement had a method that > returned a Method object corresponding to that information. Not sure where I > got that from, might have been from the CLR, I don't remember. Sorry.... > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > -----Original Message----- > > From: [email protected] [mailto:jvm- > > > [EMAIL PROTECTED] On Behalf Of Attila Szegedi > > Sent: Wednesday, January 09, 2008 12:57 AM > > To: [email protected] > > Subject: [jvm-l] Re: A better solution for artificial call frames? > > > > > > Well a StackTraceElement gives you a class name and a method name. > > You'd need a class loader to resolve these into a > > java.lang.reflect.Method object... Oh, and a method signature in case > > the method name is overloaded, as there's no reflection API for method > > lookup by line number. > > > > So, it's unfortunately not too helpful for this use... > > > > Attila. > > > > On 2008.01.09., at 9:33, Ted Neward wrote: > > > > > > > > You can already get an array of StackTraceElements, each of which > > > can give > > > you the Method that was invoked.... > > > > > > > > > > > I take it you want *mutable* access to the stack? > > > > > > Ted Neward > > > Java, .NET, XML Services > > > Consulting, Teaching, Speaking, Writing > > > http://www.tedneward.com > > > > > > > > >> -----Original Message----- > > >> From: [email protected] [mailto:jvm- > > >> [EMAIL PROTECTED] On Behalf Of Don Schwarz > > >> Sent: Tuesday, January 08, 2008 9:30 AM > > >> To: [email protected] > > >> Subject: [jvm-l] Re: A better solution for artificial call frames? > > >> > > >> > > >> On Jan 7, 2008 7:24 AM, Kresten Krab Thorup <[EMAIL PROTECTED]> > > wrote: > > >>> > > >>> Another aspect is, that frames are the only kind of object > > reference > > >>> source which is not accessible by reflection. Having some kind of > > >>> reflective access to this would allow several new behaviors in the > > >>> meta layers. > > >>> > > >> Agreed. > > >> > > >> Even just being able to get a stack of Method objects for a thread > > >> would be useful in many situations, especially when tied to > > >> reflection > > >> of Method annotations. > > > > > > > > > > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.17.13/1214 - Release Date: > > 1/8/2008 1:38 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.0/1218 - Release Date: 1/10/2008 > 1:32 PM > > > > > > > -- Like the fella says, in Italy for 30 years under the Borgias they had warfare, terror, murder, and bloodshed, but they produced Michelangelo, Leonardo da Vinci, and the Renaissance. In Switzerland they had brotherly love - they had 500 years of democracy and peace, and what did that produce? The cuckoo clock. -- Orson Welles --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
