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 <michalwadas at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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?