Discuss
  • Strawman: Function.observe

Strawman: Function.observe

# Michał Wadas (11 years ago)

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)
# Claude Pache (11 years ago)

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?

# Andreas Rossberg (11 years ago)

Won't happen. This would be a gigantic encapsulation leak, and is bound to cause security issues without end.

# Jasper St. Pierre (11 years ago)

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.