Re: Improving Function.prototype.bind

In your proposal, what does this code sequence do: Object.boundTo(Object).foo = capabilityBobShouldntGet; var HAH = Object.boundTo(Object).foo; ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

most JS developers use what their library/framework provide and the bind is most of the time transparent. Libraries developers simply use bind as a Santa Claus ES5 gift so they don't bother thinking about the pattern they are forced to use, they just use bind the way they can but again, not relyin

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 10:20 PM, Mark S. Miller wrote: > > > On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock > wrote: > > On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: > >> Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we >> were trying to arrive at two modes, E

RE: ES6 doesn't need opt-in

Jumping in late, and possibly repeating some already covered ground, but this is clearly an important topic. Looking at all the proposals on these threads, I have to throw support behind Mark's proposal below, or a close variant of it as discussed below and in some of the other branches (I thin

Re: ES6 doesn't need opt-in

On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock wrote: > > On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: > > Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we > were trying to arrive at two modes, ES6 non-strict, to be backwards compat > with ES5-non-strict, and ES6

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: > Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we > were trying to arrive at two modes, ES6 non-strict, to be backwards compat > with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. > I am perfe

Re: Improving Function.prototype.bind

Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal ambient communications channel. // initSES initialization, freezing all built in primordials other than the true global // load Alice as a confined object graph // load Bob as a confin

Fwd: [friam] Fwd: Hash Collision Denial of Service

There is currently an informal (partial?) consensus to try to add high entropy identity hashes to ES6 (but no proposal page yet), so that users can build hashtables for themselves. Were they to do so, they immediately find they'd want to include non-objects as keys as well (like Map does), and so w

Re: ES6 doesn't need opt-in

Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we were trying to arrive at two modes, ES6 non-strict, to be backwards compat with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. I am perfectly happy to call ES6 non-strict "ES3", since ES5-non-strict r

Re: ES6 doesn't need opt-in

Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics to a Program unit In an "ES6" implementation, all constructs that can occur in a valid program fit into one of these categories: ES6-only: The construct is based upon syntax or static semantics rules that only exist

Re: Improving Function.prototype.bind

On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: > Guys, by any chance we can go back into the topic? You'll have to polyfill Function.prototype.bind in the current world of pre-ES5 browsers. Why not then go on to wrap it in a memoizing version that uses a WeakMap if available (emulated wit

Re: Improving Function.prototype.bind

Guys, by any chance we can go back into the topic? I was not thinking about changing the meaning of "this" in a function, also Python sends explicit self context as first argument so things are slightly different in any case Point is: - bind was one of the most needed/used Function.prototyp

Re: Improving Function.prototype.bind

> I do not believe (Axel) that the spec's Reference internal type is helpful as > an externally-visible part of the language in any of this. I believe you, I know nothing about how references are actually implemented. Python works like this: class Foo: def bar(): pass

Re: Improving Function.prototype.bind

On Jan 5, 2012, at 8:08 AM, François REMY wrote: > >> > >> It’s a shame that we are really close in JavaScript, with the ECMA-262 > >> specification using references. > >> > > As things are going, things are not going to change. The strong desire to > avoid any behavior breakingchange between

Re: Improving Function.prototype.bind

I have to agree. I’m just convinced that you have to break compatibility at some point, or you "die". VB is a good sample. VB was great for the time he was introduced but it has many quirks. At some point, Microsoft broke compatibility, and VB.NET is born. Some developers complained, but I’m pr

Re: Improving Function.prototype.bind

leaks, performances, as example, are the first things I have in mind when I look at that code ( assuming I understand how WeakMap works there ) Function.prototype.bind could have been implemented via libraries ( as Prototype did ) as well so I don't get your argument, sorry. My point is that Func

Re: Improving Function.prototype.bind

Hi Andrea, It seems that what you want can be implemented as a library [1] (actually you did it as well in your blog post). In this gist, a cache is used. In a nutshell, it is a '(function, object) -> boundFunction' mapping. I used 2 levels of WeakMaps to achieve this. I don't think a native impl

Re: Improving Function.prototype.bind

> As things are going, things are not going to change. The strong desire to > avoid any behavior breakingchange between ES5 and ES6 actually makes it > impossible to fix a lot of issues. I’m starting to think Google may be right > to start over a new language, the comitee is too conservative abo

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 8:30 AM, Axel Rauschmayer wrote: > On Jan 5, 2012, at 1:56 , Brendan Eich wrote: > >> Better to dispense with modes or ordered versions altogether, which is the >> key idea of the proposal. > > > So, simplified, the story is: > > - ES6 is a superset of ES5.strict. That's a

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 11:10 AM, Brendan Eich wrote: >> That precluded a number of highly undesirable >> combinations, e.g. extended mode nested into a "with" statement. > > You can "use strict"; in a with statement's body block. Sorry to be unclear, I meant examples such as this: js> with ({p:1})

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 9:30 AM, Allen Wirfs-Brock wrote: > A slightly different approach to this might be to say that the use of any new > syntax implies that the immediately surrounding function or program is in > strict mode. I'm favoring program currently, even if the new syntax is used in just

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote: >>> explicit opt-in) >> >> No -- "use strict"; the string literal expression-statement is meaningless >> pre-ES5, ES5-strict in ES5, and redundant in Harmony code. > > You said earlier that we best rely on the meta tag for the script > topleve

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 11:38 PM, Mark S. Miller wrote: > In your suggestion, when an occurrence of destructuring (or any other new > syntax) is seen, what unit of code is then opting in to strict? Would it be > the nearest enclosing function, module, class, generator, or Program? I think > I'm war

Re: Improving Function.prototype.bind

all the time since I widely use private methods and I reuse them per each created instance of a specific "class" The boundTo() approach would make the method still private, immutable out there, and reusable per each instance/object I need. // stupid useless example ... just as concept var Counter

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 1:56 , Brendan Eich wrote: > Better to dispense with modes or ordered versions altogether, which is the > key idea of the proposal. So, simplified, the story is: - ES6 is a superset of ES5.strict. - Therefore, as soon as we have ES6, ES5.strict code bases automatically becom

Re: Improving Function.prototype.bind

> that would not solve much 'cause you can bind a function to a single object > and no more. Isn’t that the most frequent use case? Do you have examples where you bind the same function to several objects? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschm

Re: Improving Function.prototype.bind

>> >> It’s a shame that we are really close in JavaScript, with the ECMA-262 >> specification using references. >> As things are going, things are not going to change. The strong desire to avoid any behavior breakingchange between ES5 and ES6 actually makes it impossible to fix a lot of issues.

Re: Improving Function.prototype.bind

that would not solve much 'cause you can bind a function to a single object and no more. My proposal is object related so that eventually, even if you forget to explicitly drop already bound callbacks, those stacks should be GCed automagically and memory speaking it should be safe. @Jake I find t

Re: Improving Function.prototype.bind

On Jan 5, 2012, at 14:54 , Andrea Giammarchi wrote: > Here the whole post with better examples plus the proposed solution that > would be nice to have in JS.Next > http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html I don’t use bound() and function expressions very of

Re: ES6 doesn't need opt-in

On 4 January 2012 21:52, Brendan Eich wrote: > On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote: > >> - Despite the superficial "fewer modes" mantra, it actually doesn't >> make the language simpler, but more complicated: instead of defining >> the semantics for Harmony features only for strict-

Re: ES6 doesn't need opt-in

On 4 January 2012 21:30, Brendan Eich wrote: >> In any case, even if we allow more features in classic mode > > Don't think of modes and you'll be grooving with the new proposal better ;-). Well, I'd say "syntactic context" is just a euphemism. Or maybe the other way round... /Andreas __

Re: ES6 doesn't need opt-in

On 4 January 2012 21:27, Brendan Eich wrote: > On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote: >>> >>> Your (3) seemed to say "use module" was something distinct from (and also >>> implicit in, so a part but not the whole of what is declared by) module >>> declaration syntax. It's not -- as pr

Improving Function.prototype.bind

I have thought it may be interesting to receive some comment here too ... so here the short summary: genericCallback.bind(sameObject) !== genericCallback.bind(sameObject) quite inconvenient for listeners and leading to uncomfortable patterns ( store the bound reference somewhere and get it back l

Re: ES6 doesn't need opt-in

Considering all that, I can't help feeling that having a separate mode is cleaner, simpler, and easier to use. I think it also has more potential for providing a robust foundation for future evolution of the language. This last point -language evolution- is something that Haskellers have quite a

Re: Boolean shortcuts

Yeah, it looks. And it needs no special case in used in var. -Pôvodná správa- From: Nadav Shesek Sent: Thursday, January 05, 2012 2:00 PM To: Herby Vojčík Cc: mikesam...@gmail.com ; es-discuss@mozilla.org Subject: Re: Boolean shortcuts There was a suggestion for CoffeeScript, which go

Re: Boolean shortcuts

There was a suggestion for CoffeeScript, which got implemented by Coco, for `{+enumerable, -configurable, +writable}` syntax that does that. It has the same potential ambiguity, but looks better IMO. On Thu, Jan 5, 201