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

Mark S. Miller erights at google.com
Fri Aug 17 19:44:37 PDT 2012


On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eich <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.

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
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<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/20120817/88133d2f/attachment.html>


More information about the es-discuss mailing list