Experimental implementation of Object.observe & JS Utility library now available

Brendan Eich brendan at mozilla.org
Fri Aug 17 20:03:27 PDT 2012


Mark S. Miller wrote:
> On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eich <brendan at mozilla.org 
> <mailto:brendan at mozilla.org>> wrote:
>
>     All praise to Raf et al., my concern is that something
>     synchronous, plus event loop concurrency and setImmediate, would
>     suffice to bootstrap the rather more elaborate proposal on top of
>     the simpler O.p.watch like fundament.
>
>     This is not to say we shouldn't standardize higher-level APIs, and
>     instead push that off on library authors to write, and users to
>     download. There's a delicate balance here. We often screw up
>     higher-level abstractions in annoying ways, but perhaps that risk
>     is worth taking.
>
>     What I'm really getting at is this: why not expose the synchronous
>     primitive and e.l.c. building blocks as well?
>
>
> A synchronous observation mechanism provides an attacker too many 
> opportunities for a plan interference attack. If you'll recall, an 
> earlier synchronous proposal died for this reason.

Thanks, I recall -- but this needs to be stated clearly in the spec. I 
hear from people all the time asking Y U no Object.prototype.watch.

/be

>
> Object.observe has been carefully designed to strike a good balance 
> between providing non-malicious code useful new powers without 
> providing attackers significant new attack opportunities. The core 
> principle is that a client of an object can anyway observe changes to 
> observable state asynchronously by polling between turns. And a client 
> of an object, if it receives control during a turn, can poll while it 
> has control. To a first approximation, Object.observe can be 
> understood as an optimization of polling. It is actually more powerful 
> than that, but in ways that are beneficial without IMO creating 
> significant new hazards.
>
>
>     /be
>
>     Brandon Benvie wrote:
>
>         I agree on the above with regard to Proxies. They are awesome
>         and allow for incredible things, but Object.observe fills a
>         different use case that I think is more common at at the user
>         standpoint or at least library standpoint. When you look
>         around at the major JS libraries that exist the problem they
>         are trying to solve (after DOM normalization) is data-binding.
>         Proxy can be used to solve this for new objects or wrapped
>         objects, but that's overkill and may have performance
>         consequences, and has no support for working with existing
>         objects. Proxy and observe end up filling two completely
>         different use-cases, and I would venture to say that observe
>         is the one that most people could make better use of if they
>         had it in their hands today.
>         _______________________________________________
>         es-discuss mailing list
>         es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>         https://mail.mozilla.org/listinfo/es-discuss
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> -- 
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list