Re: Polyfilling Object.observe

> Because you are doing it wrong. Yeah, because using Proxy isn't simple like using `Object.observe`. I'm just showing that this is all extremely easy to do with `Object.observe`. > What you really want is to have new Foo() return a Proxy... which is counter-intuitive, admittedl

Re: Polyfilling Object.observe

> `Proxy` is powerful, but it's not as good as `Object.observe` would've > been for some very simple tasks. > > Every time I wish I could use `Proxy` in a simple way, there's always some > issue with it. For example: https://jsfiddle.net/trusktr/hwfontLc/17 >

Re: Polyfilling Object.observe

> Every time I wish I could use `Proxy` in a simple way, there's always some > issue with it. For example: https://jsfiddle.net/trusktr/hwfontLc/17 The main problem with that code is that the `prototype` property of a class is read-only, that's why you see no output. Blame classes instead of pro

Re: Polyfilling Object.observe

> I don't think there's any solution other than diffing And how would you diff without polling (while supporting IE)? `Proxy` is powerful, but it's not as good as `Object.observe` would've been for some very simple tasks. Every time I wish I could use `Proxy` in a sim

Re: Polyfilling Object.observe

Another caveat of my implementation, for example, is that it adds getters/setters for properties that previously didn't exist. This will break code that checks existence of props. etc. etc. That's not a problem with a theoretical `Object.observe`. */#!/*JoePea On Fri, Jul 27, 2018 a

Re: Polyfilling Object.observe

On Tue, Jul 24, 2018 at 6:50 PM, /#!/JoePea wrote: >> I don't think there's any solution other than diffing > > And how would you diff without polling (while supporting IE)? When you diff is totally up to your use case. IIRC, AngularJS used to do it upon exit from event handlers (or possibly both

Re: Polyfilling Object.observe

Proxy is limited, because it won't intercept deleteProperty or others as part of a prototype, so you need to replace the object with a proxied object, which is not exactly the same as Object.observe. On Tue, Jul 24, 2018 at 7:50 PM /#!/JoePea wrote: > > But yes, **if** you know the n

Re: Polyfilling Object.observe

or`, to make things easier. I do a similar hack now anyways in order to make ES5-style classes work with native Custom Elements. - How do we proxify a class prototype when using ES6 classes? Do we just `SomeClass.prototype = new Proxy(SomeClass.prototype, handler)`? Any implications of that? -

Re: Polyfilling Object.observe

On Tue, Jul 24, 2018 at 6:01 PM, /#!/JoePea wrote: > Is there a way to polyfill `Object.observe` in such a way that the object > before observation is the same reference as the object being observed after > the call (i.e. not a Proxy), and other than monkey-patching getters/setter

Re: Polyfilling Object.observe

ote: > Is there a way to polyfill `Object.observe` in such a way that the object > before observation is the same reference as the object being observed after > the call (i.e. not a Proxy), and other than monkey-patching getters/setters? > > Is defining getters/setters the o

Polyfilling Object.observe

Is there a way to polyfill `Object.observe` in such a way that the object before observation is the same reference as the object being observed after the call (i.e. not a Proxy), and other than monkey-patching getters/setters? Is defining getters/setters the only way? */#!/*JoePea

Re: Status of Chrome Proxy in face of Object.observe removal

I had a request for the locations of the polyfills, here they are (both MIT license): https://github.com/anywhichway/proxy-observe https://github.com/anywhichway/chrome-proxy On Fri, Nov 6, 2015 at 1:16 PM, Simon Blackwell wrote: > In the face of the announcment that the Object.obse

Re: Status of Chrome Proxy in face of Object.observe removal

On 6 November 2015 at 19:16, Simon Blackwell wrote: > In the face of the announcment that the Object.observe standard proposal is > being revoked and commentary that seems to indicate that at a minimum either > Proxy or Object.observe is needed, does anyone know the status of > re-

Status of Chrome Proxy in face of Object.observe removal

In the face of the announcment that the Object.observe standard proposal is being revoked and commentary that seems to indicate that at a minimum either Proxy or Object.observe is needed, does anyone know the status of re-introduction of Proxy into Chrome and v8? To support both Firefox and

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

ernative to Proxy.startTrapping and covers at >> least part of its use cases. > > > ​Hmm. > > Okay so pretend all object's are really just proxies to whatever their > internal backing might be. In this scenario perhaps what we might want is > `Proxy.observeTraps` which sh

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

hatever their > internal backing might be. In this scenario perhaps what we might want is > `Proxy.observeTraps` which should work just like Object.observe only > synchronously and without a baked in ability to intercede. One could, > however, respond to a set operation by resetting the old value. Wh

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

of its use cases. > > ​Hmm. > > Okay so pretend all object's are really just proxies to whatever their > internal backing might be. In this scenario perhaps what we might want is > `Proxy.observeTraps` which should work just like Object.observe only > synchronously a

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

aps what we might want is `Proxy.observeTraps` which should work just like Object.observe only synchronously and without a baked in ability to intercede. One could, however, respond to a set operation by resetting the old value. What this does is give you something VERY close to a built in obser

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

2015-11-04 23:04 GMT+01:00 Matthew Robb : > > On Wed, Nov 4, 2015 at 4:46 PM, Tom Van Cutsem wrote: > >> 1) If a module A hands out a reference to, say, a function f to modules B >> and C, then C could use this primitive to replace f with its own proxied >> version. Module B expects f to work as

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Thu, Nov 5, 2015 at 12:30 AM Romuald Quantin wrote: > What is the problem in accessing the keys with any code, which is the same > behaviour for any other object in javascript: String, Array, Object and so > on. The point is being able to do on a weak key so code can be processed > without bei

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Read esdiscuss.org, use Google site: search, before complaining that you don't understand why something is not "enabled". Here's a link: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=site%3Aesdiscuss.org%20weak%20reference It's not hard to find the full history of t

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Someone made an experiment with the Mozilla “getWeakReference” apparently. https://gist.github.com/Benvie/7123690 https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.getWeakReference I had this as granted with other languages, I still don’t understand wh

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

> 2. For security purposes, only code that has been explicitly given access to _both_ the weak map and a key may gain access to the value stored within the > weakmap. This is why there is no enumeration—if there were, then any code that could access the weak map could then also access all of the ke

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Wed, Nov 4, 2015 at 2:36 PM, Rick Waldron wrote: > On Wed, Nov 4, 2015 at 8:16 AM Coroutines wrote: >> obj[Symbol.weakValues] = true; >> obj[Symbol.weakProperties] = true; > 2. For security purposes, only code that has been explicitly given access to > _both_ the weakmap and a key may gain

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Wed, Nov 4, 2015 at 8:16 AM Coroutines wrote: > On Wed, Nov 4, 2015 at 4:56 AM, Romuald Quantin > wrote: > >> As an aside and as Coroutines, >> >> I never understood why there is this inability to enumerate WeakMap keys. >> > > If I had it my way there would be no WeakMap or WeakSet. I'd hav

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Wed, Nov 4, 2015 at 4:46 PM, Tom Van Cutsem wrote: > 1) If a module A hands out a reference to, say, a function f to modules B > and C, then C could use this primitive to replace f with its own proxied > version. Module B expects f to work as A intended, but module C can > completely override

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

2015-11-04 0:22 GMT+01:00 Coroutines : > > With Object.observe() you get a global view of events generated by the > target object, with Proxy you need to replace references to the target > object with references to the Proxy. > > Now I'm changing my opinion again. We need

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

2015-11-03 15:41 GMT+01:00 Matthew Robb : > I probably have a terrible understanding of how this all works at a low > level but I feel like a potential solution would be a method of "upgrading" > a non-proxy object to be a proxy. The reason accessors are being used as > they are now is because you

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Wed, Nov 4, 2015 at 4:56 AM, Romuald Quantin wrote: > As an aside and as Coroutines, > > I never understood why there is this inability to enumerate WeakMap keys. > If I had it my way there would be no WeakMap or WeakSet. I'd have a Symbol.mode similar to Lua's __mode meta(method/field?) tha

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

As an aside and as Coroutines, I never understood why there is this inability to enumerate WeakMap keys. Back in the time of flash/as3, I made some modules to observe objects that were garbage collected, and this was extremely useful. This was only possible because the keys were utterable. I was

Re: An update on Object.observe

> a lot of noise on this list Agreed (re: no one in particular). :-( Best to step back and study all of the stuff already in JS, before doubling down on reviving another withdrawn proposal. /be ___ es-discuss mailing list es-discuss@mozilla.org https:/

Re: An update on Object.observe

Reflect.construct basically does `new Class(...args)`, but on a lower level where you can set `new.target` in the call. Object.observe makes it easier, but sometimes, it's useful to completely break encapsulation from a closure. I've had a few use cases where I needed that ability. Ther

Re: An update on Object.observe

rstanding you but this is what I was trying to say is 'okay'. If you redefined String to be a proxy before the closure runs then that seems "legal". I disagree with Object.observe() because you can call it after the closure has run and see changes made in String (or another obj

Re: An update on Object.observe

= function () { return new s("cat"); } var public = function () { return private(); } return public; })() ``` There's no equivalent with Object.observe. I could also redefine String as a sloppy mode function and use `arguments.callee` or `Function.prototype.callee` to get the `private`

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

You can't get anything related to actual object access from Object.observe. If you observe String, you can only get the following events: - "add": String.newProp = value - "update": String.existingProp = newValue - "delete": delete String.prop - "re

Re: An update on Object.observe

Okay, so I've been making a lot of noise on this list in the last few days about Proxy and Object.observe(). I thought I would try to put up some example code to show why both should stay, but Object.observe() usage should be restricted so it's not web-accessible (debug use only).

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Tue, Nov 3, 2015 at 7:33 PM, Isiah Meadows wrote: > There's a reason Object.observe is async: it prevents you from changing how > the value is first assigned, so it can't work like a proxy. And question: > how does it let you see hidden closures? In JS it is common to w

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

I was just thinking... Object.observe could, in theory, be used as a core for a dispatcher and store in a Flux-like data flow. Basically, when a view emits an event, you can use the first observed object as a memoized dispatcher, and then it emits a list of changes that can then update another

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

There's a reason Object.observe is async: it prevents you from changing how the value is first assigned, so it can't work like a proxy. And question: how does it let you see hidden closures? On Tue, Nov 3, 2015, 18:28 Coroutines wrote: > On Tue, Nov 3, 2015 at 3:22 PM, Coro

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Tue, Nov 3, 2015 at 3:22 PM, Coroutines wrote: > But because of what Object.observe() can do to see into closures, I'd > relegate it to privileged code :> It is incredibly useful for > debugging. I really need to make sure my thoughts are complete before I send a message

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Tue, Nov 3, 2015 at 12:20 AM, Tom Van Cutsem wrote: > What O.o would provide beyond Proxy is the ability to observe changes to > already pre-existing objects. I think I missed something important here. You can watch for events with both Proxy and Object.observe() - but Object.observe(

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

For those interested in using Proxies in the future, here are the appropriate links to the two remaining holdouts (FF and MS Edge are already there): Safari/Webkit/JSC: https://bugs.webkit.org/show_bug.cgi?id=35731 Chrome/V8: https://code.google.com/p/v8/issues/detail?id=1543 Bug the appropria

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

So would I, it would open up some very efficient opportunities > On Nov 3, 2015, at 8:26 AM, Andrea Giammarchi > wrote: > > That would make functional-programming-oriented developers wining forever > about such monstrosity in specs ... I'd personally love such possibility! > > Regards > >

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Ah yes, the Smalltalk "become:" message, something that inspired SpiderMonkey's "Brain Transplants" -- see the [1] footnote at https://brendaneich.com/2010/11/proxy-inception/, and of course the bugzilla link, which leads to this: Brendan Ei

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

I'm neutral. On Tue, Nov 3, 2015, 15:43 Matthew Robb wrote: > Isiah, could you elaborate some? I can't quite tell if you are expressing > support for my suggestion or not. Thanks! > On Nov 3, 2015 12:13 PM, "Isiah Meadows" wrote: > >> Lol... I feel I'm in an insane minority that can work relati

Re: An update on Object.observe

hey support trapping for a larger number of uses - like for .. in iteration. I had started another thread to "Save Object.observe" after joining the mailing list late. I was misguided. ;> ___ es-discuss mailing list es-discuss@mozilla.org

Re: An update on Object.observe

On Tue, Nov 3, 2015 at 1:25 PM, Coroutines wrote: > On Tue, Nov 3, 2015 at 1:24 PM, Adam Klein wrote: > > > Note that O.o didn't help for the "as they happen" case anyway, as > callbacks > > were delayed until the end of the turn (same timing as Promise > resolution). > > Proxies are required to

Re: An update on Object.observe

On Tue, Nov 3, 2015 at 1:24 PM, Adam Klein wrote: > Note that O.o didn't help for the "as they happen" case anyway, as callbacks > were delayed until the end of the turn (same timing as Promise resolution). > Proxies are required to do synchronous interception. Would this be similar to .nextTick

Re: An update on Object.observe

icult-to-reason-about mechanisms on top before reeling in exotic host > > objects. With Proxy out of the bag, I'm not so hopeful for the humble > Object > > anymore. > > As far as I know, without Proxy or Object.observe() there would be no > possible way to watch for changes *as

Re: An update on Object.observe

bjects. With Proxy out of the bag, I'm not so hopeful for the humble Object > anymore. As far as I know, without Proxy or Object.observe() there would be no possible way to watch for changes *as they happen* and directly fire off an observing function or handler. You need assistance from the

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Isiah, could you elaborate some? I can't quite tell if you are expressing support for my suggestion or not. Thanks! On Nov 3, 2015 12:13 PM, "Isiah Meadows" wrote: > Lol... I feel I'm in an insane minority that can work relatively > productively in Java 7 and Haskell both. > > Of course, I have a

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Lol... I feel I'm in an insane minority that can work relatively productively in Java 7 and Haskell both. Of course, I have a preference, but that preference lies around that of OCaml and Clojure. It's more the expression-based, impure functional languages that I'm most productive in. Observing mu

Re: An update on Object.observe

On Tue, Nov 3, 2015 at 11:27 AM, lycheeJS Engine < lycheejs+esdisc...@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

Re: An update on Object.observe

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

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

That would make functional-programming-oriented developers wining forever about such monstrosity in specs ... I'd personally love such possibility! Regards On Tue, Nov 3, 2015 at 2:41 PM, Matthew Robb wrote: > I probably have a terrible understanding of how this all works at a low > level but

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

I probably have a terrible understanding of how this all works at a low level but I feel like a potential solution would be a method of "upgrading" a non-proxy object to be a proxy. The reason accessors are being used as they are now is because you can retro fit them. Maybe what I am suggesting is

Re: An update on Object.observe

On 3 November 2015 at 14:58, David Bruant wrote: > Le 03/11/2015 12:26, Alexander Jones a écrit : >> >> In my opinion, the fundamental record type we build our JS on should be >> getting dumber, not smarter. It feels inappropriate to be piling more >> difficult-to-reason-about mechanismson top bef

Re: An update on Object.observe

Hi, Le 03/11/2015 12:26, Alexander Jones a écrit : In my opinion, the fundamental record type we build our JS on should be getting dumber, not smarter. It feels inappropriate to be piling more difficult-to-reason-about mechanismson top before reeling in exotic host objects. JS objects were nev

Re: An update on Object.observe

Just to be clear: 1. I am very happy O.o is gone 2. in my experience it's repeatedly clear that whatever proposal that cannot be polyfilled will have hard time to be widely adopted. As example, O.o has never been in other browsers so, unless you are targeting Chrome and Chrome only, it's kind

Re: An update on Object.observe

In my opinion, the fundamental record type we build our JS on should be getting dumber, not smarter. It feels inappropriate to be piling more difficult-to-reason-about mechanisms on top before reeling in exotic host objects. With Proxy out of the bag, I'm not so hopeful for the humble Object anymor

Re: An update on Object.observe

Sure thing, meanwhile polymer or other libraries need to pollute getters and setters and the rest of the web have been trying to polyfill it for at least 6 years now * The reason is not widely "abused" is that it never made it as standard and as it is feels like an outdated spec. Proxy would give

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

2015-11-02 23:34 GMT+01:00 Coroutines : > > I come from Lua. In Lua we make proxy objects with metamethods. You > create an empty table/object and define a metatable with a __index and > __newindex to catch accesses and changes when a key/property doesn't > exist. I would primarily use this in s

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

it should not have been collected. > unless I've misunderstood the intent itself, Object.observe as it has > been proposed wouldn't help much anyway. > > Regards > > On Mon, Nov 2, 2015 at 10:34 PM, Coroutines wrote: > >> I was referred to es-discuss after filin

Re: An update on Object.observe

On 11/2/15 4:55 PM, Andrea Giammarchi wrote: I agree with Benoit and I think there is a reason `Object.prototype.watch` is still in Firefox and won't go away any time soon As far as I know the only reason it's there and hasn't been removed is because it's used to implement debugger watchpoint

Re: Re: An update on Object.observe

To be clear, I'm neither for nor against this (I do not fully know the use-cases or caveats of Object.observe). However, short timelines are an easy way to cause deep pain in the node ecosystem. ~Jeremiah ___ es-discuss mailing list es-di

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Not sure I've got your idea right but I think the main point of WeakAnything is to forget about GC and have them **not** observable "at all costs" unless I've misunderstood the intent itself, Object.observe as it has been proposed wouldn't help much anyway. Regards

Save Object.observe()! (please) + make WeakMap/WeakSet observable.

I was referred to es-discuss after filing a feature request here to support observing WeakMaps and WeakSets. ( https://bugzilla.mozilla.org/show_bug.cgi?id=1206584 ) I was linked this message: https://mail.mozilla.org/pipermail/es-discuss/2015-November/044684.html Please save Object.observe

Re: An update on Object.observe

ears ago, Rafael Weinstein, Erik Arvidsson, and I set out to > design and implement what we believed to be the primitive underlying the > data-binding system of MDV ("model-driven views"). We prototyped an > implementation in a branch of V8, then got agreement from the V8 team to

Re: An update on Object.observe

Hi there. This is Jeremiah Senkpiel aka Fishrock123 from the Node.js TSC. Because of how the node module ecosystem works removing features is able to have great destructive impact on us. As such I'd like if extra considerations could be made beyond just chrome's usage. Getting stats is harder b

Re: An update on Object.observe

ears ago, Rafael Weinstein, Erik Arvidsson, and I set out to >> design and implement what we believed to be the primitive underlying the >> data-binding system of MDV ("model-driven views"). We prototyped an >> implementation in a branch of V8, then got agreement fr

Re: An update on Object.observe

e > data-binding system of MDV ("model-driven views"). We prototyped an > implementation in a branch of V8, then got agreement from the V8 team to > build a real version upstream, while pushing Object.observe ("O.o") as a > part of the upcoming ES7 standard and working

Re: An update on Object.observe

version upstream, while pushing Object.observe ("O.o") as a part > of the upcoming ES7 standard and working with the Polymer team to build their > data-binding system on top of O.o. > > Three years later, the world has changed in a variety of ways. While other > data-binding framew

Re: An update on Object.observe

ews"). We prototyped an >> implementation in a branch of V8, then got agreement from the V8 team to >> build a real version upstream, while pushing Object.observe ("O.o") as a >> part of the upcoming ES7 standard and working with the Polymer team to >> build their data-bindin

Re: An update on Object.observe

nt from the V8 team to > build a real version upstream, while pushing Object.observe ("O.o") as a > part of the upcoming ES7 standard and working with the Polymer team to > build their data-binding system on top of O.o. > > Three years later, the world has changed in a variety

An update on Object.observe

to build a real version upstream, while pushing Object.observe ("O.o") as a part of the upcoming ES7 standard and working with the Polymer team to build their data-binding system on top of O.o. Three years later, the world has changed in a variety of ways. While other data-binding framework

Fwd: Object.observe deep tree topic

Hi all, Not sure how to start it, so posting here, please correct me if it's misuse of this list. I've looked into a threads of the last year and didn't find any discussion regarding deep Object.observe feature (as well as something like setPath/getPath functionality), and would l

Re: Object.observe and deliverChangeRecords

/edit?js,console > > HTH > > > On Tue, Sep 9, 2014 at 9:50 PM, Jeremy Darling > wrote: > >> I maintain a Shim of Object.observe ( >> https://github.com/jdarling/Object.observe) that has been gaining in >> popularity since Chrome implemented the functionality

Re: Object.observe and deliverChangeRecords

Object.deliverChangeRecords is to get a synchronous delivery to the function that is listening to the mutations. http://jsbin.com/qazipicipume/1/edit?js,console HTH On Tue, Sep 9, 2014 at 9:50 PM, Jeremy Darling wrote: > I maintain a Shim of Object.observe ( > https://github.com/jdarling/Object.observe) th

Object.observe and deliverChangeRecords

I maintain a Shim of Object.observe ( https://github.com/jdarling/Object.observe) that has been gaining in popularity since Chrome implemented the functionality in their public release. It had some usage before but it has really started picking up since. That being beside the point, someone

Object.observe

At the last meeting, I expressed some concern I had about Object.observe based on feedback I got from Kris Selden of the Ember Core team (the primary maintainer of our binding system and all-around performance guru). At the meeting, I was under the wrong impression that Kris had attempted to

Re: Object.observe feedback

ely? > > - Here is the perspective that I am taking. At the moment I’m > teaching my teenagers Javascript for an app they are building and in the > interest of not confusing them, I’m trying to stick to VanillaJS so they > don’t get confused about what is JS and what is

Re: Object.observe feedback

on 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 the latest spec for Object.observe] > > Basically, you're making an assumption about processing log data

Re: Object.observe feedback

implements the latest spec for Object.observe] Basically, you're making an assumption about processing log data which is understandable, but unfortunately false. Though it would be nice, it's simply not possible to process each change record by looking at the final state of the observed obj

Re: Changes to Object.observe based on feedback from the September discussion

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 wrote: > At the September meeting, the committee discussed Object.observe. Below is > a summary

Re: Changes to Object.observe based on feedback from the September discussion

On Thu, Oct 17, 2013 at 3:09 PM, Rafael Weinstein wrote: > 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

Re: Changes to Object.observe based on feedback from the September discussion

On Thu, Oct 17, 2013 at 3:09 PM, Rafael Weinstein wrote: > 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

Changes to Object.observe based on feedback from the September discussion

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

Re: Object.observe inital polyfill

t; See < https://github.com/tvcutsem/harmony-reflect/blob/master/examples/observer.js> for an implementation of that approach (usage example is here < https://github.com/tvcutsem/harmony-reflect/blob/master/examples/observer.html >. It was based on the original spec. for Object.observe. It may

Re: Object.observe inital polyfill

pable environments too. Maybe we can share some thoughts on it a part. br On Fri, Nov 30, 2012 at 1:06 PM, Jeremy Darling wrote: > We are looking at using Object.observe in a current project as it will > ease our development time greatly. To that avail I've created a simple > (call

Object.observe inital polyfill

We are looking at using Object.observe in a current project as it will ease our development time greatly. To that avail I've created a simple (call it proof of concept) polyfill/shim (whats the difference?) ( https://github.com/jdarling/Object.observe) that compares quite well with the Chr

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

In my experience, it is very common to want to process changeRecords that were created, even if you letter turned off the observer. Turning off observers (in particular, temporarily), can be useful for avoiding certain kinds of cycles when creating bidrectional links. On Sat, Nov 3, 2012 at 11:19

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

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 wrote: > fair enough, but I want to kn

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

fair enough, but I want to know what I am seeing is recorded and the TV is switched off ... how? Flagging records? Flagging objects? Via getNotifier ? On Fri, Nov 2, 2012 at 11:56 AM, Erik Arvidsson wrote: > On Fri, Nov 2, 2012 at 12:22 PM, Andrea Giammarchi > wrote: > > How to make this simple

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

On Fri, Nov 2, 2012 at 12:22 PM, Andrea Giammarchi wrote: > How to make this simple ... if I switch off the TV I don't expect any eco > after ... I don't care about the program, it should not bother me. If you stick to the TV analogy... You don't want Tivo to erase what it just recorded just beca

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

ay to know if an object is being observed or not? On Fri, Nov 2, 2012 at 9:14 AM, Rafael Weinstein wrote: > Take for example: > > function myCallback(recs) { > console.log(recs.length); > } > > var obj = {}; > Object.observe(obj, myCallback); > obj.a = 1; // en

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

Take for example: function myCallback(recs) { console.log(recs.length); } var obj = {}; Object.observe(obj, myCallback); obj.a = 1; // enqueues changeRecord obj.b = 2; // enqueues changeRecord Object.unobserve(obj, myCallback); obj.c = 3; // does not enqueue changeRecord In the above

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

next tick. Thoughts? On Fri, Nov 2, 2012 at 5:17 AM, Rafael Weinstein 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

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

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

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

normative and it doesn't say anything about timing. > and the fact it should show something in console while in my opinion that > should show nothing since the Object.unobserve is called in the same "tick" The delivery of the mutation records is async, not the calls to Object.obser

Synchronous Object.observe but Asynchronous Object.unobserve ?

Just wondering if this is actually meant/expected, I am talking about the example here: http://wiki.ecmascript.org/doku.php?id=harmony:observe#example and the fact it should show something in console while in my opinion that should show nothing since the Object.unobserve is called in the same "ti

  1   2   >