> 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:/
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
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 Reflect.construct(target, newTarget, ar
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 = functio
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 =
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 night. They support
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
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
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
> > difficult-to-reason-about mechanism
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
> objects. With Proxy
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 mes
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 ha
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
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
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
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
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
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
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-discuss@mozilla.
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 chan
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
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 wrote:
>
> Regardin
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 my
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 obse
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 prototyped an
>> implementatio
> 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
> bu
26 matches
Mail list logo