An update on Object.observe

Mark S. Miller erights at
Tue Nov 3 17:01:43 UTC 2015

On Tue, Nov 3, 2015 at 11:27 AM, lycheeJS Engine <
lycheejs+esdiscuss at> wrote:

> I think we still need Object.observe as a specification to implement
> proper sandboxing of feature-detecting closures.

What do you mean by "sandbox"?

(I was not able to make sense of the rest of this message using my normal
understanding of "sandbox".)

> For example, in lycheeJS we have a sandboxing system that can inject
> definitions (and their variants) at runtime, replaces them intelligently at
> runtime. The definition closures have, for that purpose, all a supports()
> and exports() method. Both are using a referenced object that is sandboxed.
> The global property therefore is just a reference to a custom object, so
> that we can trace the properties, data types and causes of the errors.
> The implementation got stuck because of missing support for ES6 Proxies in
> the wild, but the idea is to use them to figure out if an implementation is
> doing something like window.addEventListener('asdasd') in the background
> and escalating an error up to a delegation handler that figures out what to
> do and what to inject to run it again. It is necessary to not only track
> properties and their data type; we need a feature to track if it was a
> function that threw an error or not.
> Easy use case:
> Imagine a var sandbox = { setTimeout: window.setTimeout }; This would
> throw a context error and we would need that information with proper
> description on what happened in order to isolate setTimeout and inject our
> In-JS Debugger there.
> We think Object.observe is an essential feature to have the simulation
> part of this, because we need desperately the capabilities to have a
> in-JS-written Debugger that can find such issues for our training of the
> Graph NN. The execution time aspect of this is a show-stopper if it would
> not be possible.
> Advanced use case:
> We don't use a RendererFactory that is executed once a new Renderer is
> instantiated, we have multiple Renderer implementations for multiple
> platforms available. Each Renderer has its own platform
> (fertilizer)-specific implementation. Those implementations are called
> alternative Definitions.
> Each definition has a supports() method that is called once the runtime
> error-determination algorithm tries to inject a new instance of the
> Renderer somewhere or de-reference an old, now slowly running Renderer.
> The supports() method can have all kinds of ES5 / ES6 code in order for
> the determination; it is the essential point to determine the capabilities
> of the runtime - at the given execution time, not compile time.
> If, for example, the canvas binding in the runtime on Android has problems
> now and throws some errors; there might be a fallback implementation
> available (SDL / OpenGL / GLUT / whatever) and then the Environment sandbox
> updates its dependencies accordingly and tries out "if one of the fallback
> implementation would be supported right now".
> Therefore, we think that Object.observe is quite necessary for our
> live-update-and-inject algorithms to determine compatibility problems for
> out-rolled updates _before_ they are applied to have proper feedback for
> our NN on the other peer-side of things.
> PS:
> In case anyone is interested, the problem for which we would need
> Object.observe and ES6 Proxies available, is here:
> But I could be totally all-wrong with this. If the described features are
> possible to be implemented with ES6 Proxies alone, I'm fine with
> deprecating Object.observe and with switching to ES6 Proxies. But the
> features are essential for us to choose ES6/ES7 as a language and I hope
> that others have similar feature requests.
> ~Chris
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list