An update on Object.observe

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


On Tue, Nov 3, 2015 at 11:27 AM, lycheeJS Engine <
lycheejs+esdiscuss at gmail.com> 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:
> https://github.com/Artificial-Engineering/lycheeJS/blob/development-0.9/lychee/source/core/Environment.js#L112
>
>
> 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151103/2b894856/attachment-0001.html>


More information about the es-discuss mailing list