a future caller alternative ?

Kevin Gadd kevin.gadd at gmail.com
Sat Mar 9 16:56:34 PST 2013

I really don't understand why the debugger thing is being trotted out
again. It was addressed at the beginning of the thread: There are lots
of real world applications that use debugger-style introspection (in
particular, stack walking) for purposes that are not debugging.

Now, to be fair, that may not justify exposing any of those features
if the security threat posed by having introspection is so incredibly
dire. But 'just use a debugger API' isn't really a solution for any of
these applications. Debugger APIs are heavyweight and usually have
tremendous performance consequences, preventing their use for solving
Application Problems. In reality, the answer will have to be 'you
can't do that in JavaScript', which probably isn't the end of the
world since that's the current answer to anything that needs weak


On Sat, Mar 9, 2013 at 4:54 PM, Andrea Giammarchi
<andrea.giammarchi at gmail.com> wrote:
> I do NOT want to write a debugger and yet I need caller, can you imagine ?
> Andrea
> On Sat, Mar 9, 2013 at 10:44 AM, David Bruant <bruant.d at gmail.com> wrote:
>> Le 08/03/2013 22:19, Andrea Giammarchi a écrit :
>>> This opens doors to debuggers (introspection) and APIs magic quite a lot.
>> If you want to write a debugger, use a debugger API [1] which is only
>> executed in privileged environments, no?
>> Debuggers are useful, but pierce encapsulation which is useful for program
>> integrity. I don't think making a debugger API available to all programs is
>> a good idea.
>> David
>> [1]
>> https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Guide
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list