this works. But you asked for feedback. Let me know
your thoughts.
Don
P.S. – happy to add any of this to jsbin if you’d like to see it more
closely with my testing scripts.
*From:* Rafael Weinstein [mailto:rafa...@google.com]
*Sent:* Sunday, February 16, 2014 8:06 AM
Hi Don,
Thanks for the thoughtful feedback. I'm very glad you're excited about the
feature. The short answer to your question is: the data you want is
provided, but your processing needs to be more sophisticated.
[BTW, The Chrome/V8 implementation (to the best of my knowledge) fully
implements
BTW, here's your example using observe-js:
http://jsbin.com/leh/1/edit
On Sun, Feb 16, 2014 at 7:50 AM, Rafael Weinstein rafa...@google.comwrote:
Hi Don,
Thanks for the thoughtful feedback. I'm very glad you're excited about the
feature. The short answer to your question is: the data you
Nit: 9.1.10 [[Delete]] (P)
Steps 5 6 should be steps 4a 4b (lost an indent)
On Fri, Nov 8, 2013 at 12:25 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
PDFs and .doc file available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#november_8_2013_draft_rev_21
Note that these proposed changes are now reflected in the Object.observe
spec text:
http://wiki.ecmascript.org/doku.php?id=harmony:observe
On Thu, Oct 17, 2013 at 3:09 PM, Rafael Weinstein rafa...@google.comwrote:
At the September meeting, the committee discussed Object.observe. Below
At the September meeting, the committee discussed Object.observe. Below is
a summary of the feedback, along with proposed changes to the spec.
1) Inconsistent naming of changeRecord types
The spec currently defines the following types: 'new', 'updated',
'deleted', 'reconfigured', 'prototype'
On Thu, Oct 17, 2013 at 3:09 PM, Rafael Weinstein rafa...@google.comwrote:
At the September meeting, the committee discussed Object.observe. Below is
a summary of the feedback, along with proposed changes to the spec.
1) Inconsistent naming of changeRecord types
The spec currently defines
On Thu, Oct 17, 2013 at 3:09 PM, Rafael Weinstein rafa...@google.comwrote:
At the September meeting, the committee discussed Object.observe. Below is
a summary of the feedback, along with proposed changes to the spec.
1) Inconsistent naming of changeRecord types
The spec currently defines
FWIW,
I very much agree with Dave on this point. My conceptual model for
microtask work is just a re-ordering of work which otherwise would
have run synchronously, but wanted to be run with a fresh stack.
Microtask non-termination should not be different from regular
script non-termination.
On
If you wish, you can maintain a WeakMap of observed objects. If you
wish to never process a changeRecord for an object you've stopped
observing, you can simply check the WeakMap to see if it's still
observed.
On Fri, Nov 2, 2012 at 9:50 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Andrea,
I believe the example is correct. The way the API works is this:
Object.observe and Object.unobserve both *synchronously*
register/unregister your callback as observing/unobserving any given
object. The asynchrony has to do with having changeRecords delivered
-- that happens
would implement this is that when the Object.unobserve(obj) is
called, the queue, if any, with all previous records, is delivered at that
time, and not during the next tick.
Thoughts?
On Fri, Nov 2, 2012 at 5:17 AM, Rafael Weinstein rafa...@chromium.org
wrote:
Andrea,
I believe the example
[Sorry, this time from the right email]
Object.deliverChangeRecords allows A to be a strategy in the possible
future that Steve describes (if reads were to generate changeRecords)
[Just to be clear: I *don't* think it makes sense to include reads in
the set of changeRecords generated by
Hi François,
Thanks so much for your thoughtful consideration of the
Object.observe() proposal. Here's my take on your counter-proposal:
Interestingly, what you've focused on is the one thing we
intentionally left out of the Object.observe() proposal, namely:
observing computed properties. In
Steve Sanderson (author of the excellent KnockoutJS framework) and
François REMY both raised the issue of observing computed properties
WRT to the Object.observe() proposal.
Having thought about this problem while helping to author
Object.observe, my thoughts are as follows:
First, I think you
Hi Steve,
Thanks for joining the conversation. =-)
The automatic dependency discovery that Knockout does is rather cool.
My sense has been that Proxy is a better tool for this job than is
expanding the semantics of Object.observe() to include reads.
Object.observe() only operates on objects
On Sun, Aug 19, 2012 at 11:25 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Fri, Aug 17, 2012 at 9:49 PM, Rafael Weinstein rafa...@chromium.org
wrote:
A synchronous observation mechanism provides an attacker too many
opportunities for a plan interference attack. If you'll recall
On Sat, Aug 18, 2012 at 3:06 PM, Brendan Eich bren...@mozilla.org wrote:
Rafael Weinstein wrote:
On Fri, Aug 17, 2012 at 8:03 PM, Brendan Eichbren...@mozilla.org wrote:
Mark S. Miller wrote:
On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eichbren...@mozilla.org
mailto:bren...@mozilla.org wrote
Hi gaz,
Thanks so much for your time.
Much care has been taking with this proposal to ensure that it is
neutral with respect to the existing JS Object/Security model.
As I understand it, the core vulnerability with JSON hacking is the
ability to define getters on the Object prototype.
On Fri, Aug 17, 2012 at 8:03 PM, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
All praise to Raf et al., my concern is that something
synchronous, plus event loop
I've created a bunch of cool demos and a video which attempts to
explain the use cases need for Object.observe().
https://plus.google.com/u/1/111386188573471152118
On Mon, Aug 13, 2012 at 12:28 PM, Rafael Weinstein rafa...@chromium.org wrote:
Hi all,
As promised, here is an experimental
Hi all,
As promised, here is an experimental implementation of the
Object.observe strawman in a branch of v8:
https://github.com/rafaelw/v8
[Note that there are Mac Windows binaries of Chromium for everyone's
convenience. The links to the binaries are contained in the README.md
-- and also at
On Mon, Jul 30, 2012 at 2:56 PM, Aymeric Vitte vitteayme...@gmail.com wrote:
Le 28/07/2012 01:55, Rick Waldron a écrit :
Explanation of specification history and roots in newer DOM mutation
mechanism.
AWB: Is this sufficient for implementing DOM mutation event mechanisms?
RWS: Yes, those
On Wed, Jul 18, 2012 at 3:20 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Tue, Jul 17, 2012 at 8:25 PM, Russell Leggett
russell.legg...@gmail.com wrote:
One of the absolutely most useful things I would not want to live without in
a databinding framework is bind to properties or
24 matches
Mail list logo
