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

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

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

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

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

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

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

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

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

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

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 - "reconfigure": Object.defineProperty(String, ...) -

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

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

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

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