It sounds like you want a standardized debugger and profiler API, rather
than a language feature. Every engine is different enough internally that I
don't think it makes sense to have a standardized debugger API.

That said, the Mozilla Debugger API is quite impressive. It might make
sense to look at standardizing a subset of that.

On Mon, Sep 29, 2014 at 2:20 AM, Andreas Rossberg <rossberg at google.com>
wrote:

> On 28 September 2014 20:34, Michał Wadas <michalwadas at gmail.com> wrote:
> > We have Object.observe (asynchronous callback whenever object
> > properties changes), but do we need Function.observe (asynchronous
> > callback whenever function is called)?
> >
> > Cons:
> > - can prevent many optimizations (but Object.observe too)
> >
> > Pros:
> > - allows easy debugging and profiling
> > - allows extending libraries functionalities without modyfing their
> > code (widgets?)
> >
> > What should be eventually received by callback code? Possible options:
> > - arguments (can prevent certain optimizations; critical for debugging
> > and  profiling)
> > - caller
> > - callee
> > - function's execution time
> > - thisArg of observed function (critical for observing methods of
> prototype)
>
> Won't happen. This would be a _gigantic_ encapsulation leak, and is
> bound to cause security issues without end.
>
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140929/5f14f49e/attachment.html>

It sounds like you want a standardized debugger and profiler API, rather
than a language feature. Every engine is different enough internally that I
don't think it makes sense to have a standardized debugger API.

That said, the Mozilla Debugger API is quite impressive. It might make
sense to look at standardizing a subset of that.