Re: Strawman: Function.observe
On 28 September 2014 20:34, Michał Wadas michalwa...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Strawman: Function.observe
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 rossb...@google.com wrote: On 28 September 2014 20:34, Michał Wadas michalwa...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jasper ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Strawman: Function.observe
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) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Strawman: Function.observe
Beware not to resurrect function.{caller,callee,arguments}, that were killed
(in strict mode) for good reason. With your proposal, you will be able to
observe objects that otherwise you haven't access to. I think that, at the very
least, you should forget `arguments` and `thisArg`, and, instead of `callee`
and `caller`, you should content yourself with a stack trace (what you get with
`(new Error).stack` in some engines).
One of the motivation of the proposal is easier debugging and profiling. Maybe
a debugger is a better tool for that purpose?
—Claude
Le 28 sept. 2014 à 20:34, Michał Wadas michalwa...@gmail.com a écrit :
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)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
