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

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: 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 sense of the rest of this

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

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

Re: An update on Object.observe

On Tue, Nov 3, 2015 at 3:26 AM, Alexander Jones wrote: > 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 >

Re: An update on Object.observe

On Tue, Nov 3, 2015 at 1:18 PM, Coroutines wrote: > On Tue, Nov 3, 2015 at 3:26 AM, Alexander Jones wrote: > > 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 >

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). var target =

Re: An update on Object.observe

On Tue, Nov 3, 2015 at 10:08 PM, Isiah Meadows wrote: > Proxies can do a better, more thorough job of breaking encapsulation. > > ```js > var log = []; > String = new Proxy(String, { > construct(target, newTarget, args) { > log.push(args); > return

Re: An update on Object.observe

Proxies can do a better, more thorough job of breaking encapsulation. ```js var log = []; String = new Proxy(String, { construct(target, newTarget, args) { log.push(args); return Reflect.construct(target, newTarget, args); } }); (function () { var s = String; var private =

Re: An update on Object.observe

On Tue, Nov 3, 2015 at 2:25 PM, Adam Klein wrote: > Yes, similar to nextTick() (and I agree that's better than polling, > conceptually). But Proxies are strictly more powerful. I agree as well - I had skipped over learning about Proxies until someone told me about them last

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. There's been a

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

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

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

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: 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

An update on Object.observe

Over three years 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 build a

Re: An update on Object.observe

Hi Adam, Just sharing my $0.02 : I implemented a two-way binding system in my first JavaScript framework at Apple in 2007, designed as a layer on top of a property change observing API, like in Cocoa, and that’s still our design in Montage today. I’ve never felt the need nor understood why

Re: An update on Object.observe

> Over three years 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

Regarding the Polymer 1.0 situation, as a client the new system seems to be simpler. The core aspect is that now when you modify a property, the resulting changes propagate instantly. O.o required update callbacks to be executed on a new microtask after the associated field/item was modified. In

Re: An update on Object.observe

Agreed, another aspect that I never understood, and was a problem with Angular 1.0 bindings. At least when doing it in-line, bindings don’t introduce a new flow compared to what a developer’s custom equivalent code would do. Benoit > On Nov 2, 2015, at 11:35 AM, Brian Chin

Re: An update on Object.observe

On Mon, Nov 2, 2015 at 11:21 AM, Matthew Phillips wrote: > > Over three years 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

Re: An update on Object.observe

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 well as I think there is a reason everyone would like to play with Proxies instead, but regardless in ES2015 these are still basically nowhere. Debouncing some

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

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