An update on Object.observe

lycheeJS Engine lycheejs+esdiscuss at
Tue Nov 3 16:27:00 UTC 2015

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

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.


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.

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

More information about the es-discuss mailing list