Re: ES6 doesn't need opt-in

On Fri, Jan 6, 2012 at 12:29 PM, Brendan Eich wrote: > On Jan 6, 2012, at 12:09 PM, Axel Rauschmayer wrote: > > >> Rather, we should minimize the state machine and how we talk about it. > We could generalize it using Curr, Next, Curr&Next, and Curr-Next labels. > > > > I’m awfully sorry for belab

Re: ES6 doesn't need opt-in

On Fri, Jan 6, 2012 at 12:25 PM, Allen Wirfs-Brock wrote: [...] > Other ES5 opt-ins at the top level include: > > var arguments; > > function ES5(yes,yes){}; > Please stop calling these ES5 opt-ins. They preclude the Program from being strict, and so are forcing ES5-not-strict. Non confusing name

Re: ES6 doesn't need opt-in

Axel, thanks. This is the critical point, so no apologies needed for belaboring. Allen, what I mean is exactly what Axel says here. Look at it another way. Right now we have two normative modes: ES5 strict and ES5 non-strict. State machine aside, ES6 introduces a new single mode normative spec. If

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 1:35 PM, Axel Rauschmayer wrote: >> The issue is *how* the spec and implementations decide what is supported, >> and when to raise an error on new syntax mixed (after) old non-strict code >> (e.g., 'with'). > > > Ah, OK. I thought that one would be able to lump together ES5.

RFC: Empowered data - unification of code block and object literal (and class)

This proposal tries not to add new entities into the language, it only tries to take what already is there and reusing it mercilessly. Also number of abstractions is lowered, since some of them could be implemented with existing ones, with minimal changes. The result is compact, lesser, more un

Re: ES6 doesn't need opt-in

> The issue is *how* the spec and implementations decide what is supported, and > when to raise an error on new syntax mixed (after) old non-strict code (e.g., > 'with'). Ah, OK. I thought that one would be able to lump together ES5.non-strict and all prior ES versions on one hand and ES6 and

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 1:03 PM, Axel Rauschmayer wrote: >>> Then I would only expect two labels: ES6 and non-strict >> >> You're counting different beans from Mark's "modes" and from Allen's states. >> >> The reason the state machine matters is implementation (including the fine >> spec, the normat

Re: ES6 doesn't need opt-in

>> Then I would only expect two labels: ES6 and non-strict > > You're counting different beans from Mark's "modes" and from Allen's states. > > The reason the state machine matters is implementation (including the fine > spec, the normative implementation). Authors can think of writing non-stric

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 12:25 PM, Allen Wirfs-Brock wrote: > On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote: > >> Or (no quotes) >> >> use strict; >> >> I think we want this pragma supported, not only the string-literal >> expression-statement "directive". > > If we end up with all of ES6 being a

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 12:09 PM, Axel Rauschmayer wrote: >> Rather, we should minimize the state machine and how we talk about it. We >> could generalize it using Curr, Next, Curr&Next, and Curr-Next labels. > > I’m awfully sorry for belaboring this point. But the labels and the quote > below don’t

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote: > (This grew out of a conversation Allen and I had yesterday -- great to see it > developed.) > > One thing to make clear: > >> ES5~EAS6: The construct has identical syntax and static semantics in both >> ES5 and ES6, but differing semantics.

Re: ES6 doesn't need opt-in

> Rather, we should minimize the state machine and how we talk about it. We > could generalize it using Curr, Next, Curr&Next, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: >> - ES6 is a superset of ES5

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote: > AFAICT, this agrees with my analysis of what your proposal means. How does > this not result in three modes? I guess I don't understand exactly what you mean by a "mode" or why the number of modes is particularly interesting. >From an imple

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote: > AFAICT, this agrees with my analysis of what your proposal means. How does > this not result in three modes? Counting modes is not productive, is it? All major implementations have extended ES5. It's likely extensions will continue to precede

Re: ES6 doesn't need opt-in

(This grew out of a conversation Allen and I had yesterday -- great to see it developed.) One thing to make clear: > ES5~EAS6: The construct has identical syntax and static semantics in both > ES5 and ES6, but differing semantics. For example, accessing a formal > parameter after an assignme

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 10:02 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: [...] > 1. everyone can WeakMap = function () {}; anywhere >>> >> >> Again, no they can't because all whitelisted global variables are >> unassignable. >> >> > it's a var WeakMap in the global scope ... still

Re: ES6 doesn't need opt-in

AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes? On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock wrote: > > On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: > > > No sorry, I just spotted the flaw. The observable difference is that a >

Re: Improving Function.prototype.bind

Maybe interesting for others too, since we talked about WeakMap a lot in this thread: My essential polyfill here: https://gist.github.com/1571878 100% code coverage here: https://gist.github.com/1571887 Best Regards, Andrea Giammarchi ___ es-discus

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 6:56 PM, Mark S. Miller wrote: > > > On Fri, Jan 6, 2012 at 9:27 AM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> that whole variable can be redefined or used as communication channel ... >> I really don't understand what is the problem. > > > The variable

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 9:27 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > that whole variable can be redefined or used as communication channel ... > I really don't understand what is the problem. The variable "Object"? No, in SES that's unassignable. As layered on ES5, we enforc

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: > No sorry, I just spotted the flaw. The observable difference is that a > conforming browser is not required by the (ES5 + ES6) specs to provide any > non-triggering ES6 features for program #2. In that case, we again have three > mode. > > F

Re: Improving Function.prototype.bind

that whole variable can be redefined or used as communication channel ... I really don't understand what is the problem. The returned bound once object could be frozen without problems but if the function is private with the gist I have posted: 1. you cannot redefine Object.prototype at all 2.

Re: Improving Function.prototype.bind

Yes. Under SES, Object is shared by Alice and Bob (and Carol). But it is not a communications channel since it (and all its methods, etc) are all frozen. On Fri, Jan 6, 2012 at 9:02 AM, François REMY wrote: > Sorry, I don’t understand how. [[boundFunctions]] is not readable from > the script it

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 1:50 AM, David Bruant wrote: > Le 06/01/2012 10:40, Andrea Giammarchi a écrit : > > if WeakMaps are so smart ... it means we cannot shim them without causing > leaks in non WeakMap ready browsers since no magic will happen,objects as > keys will simply be persistent in the

Re: Improving Function.prototype.bind

Sorry, I don’t understand how. [[boundFunctions]] is not readable from the script itself, only from the UA. To retreive an element from [[boundFunctions]] you need the original function used to create it. If you’ve recieved an instance to that function, you already have a communication channel,

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 1:31 AM, David Bruant wrote: [...] > David's WeakMap approach elegantly avoid this problem, because Alice and >> Bob can only communicate if they already share access to this WeakMap, in >> which case they could already communicate anyway. >> > Are you talking about > http

Re: Improving Function.prototype.bind

Le 06/01/2012 17:43, Mark S. Miller a écrit : On Fri, Jan 6, 2012 at 8:31 AM, David Bruant > wrote: Le 06/01/2012 06:03, Mark S. Miller a écrit : Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal am

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 1:29 AM, François REMY wrote: > Such an implementation would be very slow and not efficient, because > searching for a key in the "boundFunctions" weakmap would take time. It can > be a polyfill solution but a new implementation need something better. > > I think the solutio

Re: Improving Function.prototype.bind

Alice wouldn't normally be able to communicate 'bound' to Bob, and thus Bob wouldn't be able to read Alice's 'bound.foo'. The issue is much like ES3's mistake of evaluation a RegExp literal once to a RegExp object -- everyone executing the same code could now communicate, even if all accessible pri

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 8:31 AM, David Bruant wrote: > Le 06/01/2012 06:03, Mark S. Miller a écrit : > >> 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

Re: Improving Function.prototype.bind

If the case I show is not a problem, as you see with AMD loaders and decent practices the problem does not exist with my approach while problems like this exists today everywhere for those exposed objects through namespaces or even modules. Attaching instances properties runtime to bound functions

Re: Improving Function.prototype.bind

Le 06/01/2012 06:03, Mark S. Miller a écrit : 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

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

Yes, that example is indeed much worse than this dos attack. But the fix does not need random prefixes, and indeed random prefixes are way overkill. http://code.google.com/p/es-lab/source/browse/trunk/src/ses/StringMap.jssolves this problem by simply using "$" as a suffix on a fresh object that inh

Re: Improving Function.prototype.bind

Le 06/01/2012 16:54, Andrea Giammarchi a écrit : there is no security issue ... it's meant like that plus what Mark did not think about, is that if I use (function () { function callback() {} var object = {}; window.addEventListener("no way", object.boundTo(callback), false); //

Re: ES6 doesn't need opt-in

No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named fun

Re: Improving Function.prototype.bind

there is no security issue ... it's meant like that plus what Mark did not think about, is that if I use (function () { function callback() {} var object = {}; window.addEventListener("no way", object.boundTo(callback), false); // later on window.removeEventListener("no way", o

Re: Improving Function.prototype.bind

Le 06/01/2012 12:51, Andrea Giammarchi a écrit : unreachable without reference count? do you have an example different from a private scope object that is reachable from that scope so I would not call it unreachable? I'm not sure I understand your question. In IE6 (7? 8?), written naively, even

Re: ES6 doesn't need opt-in

-Pôvodná správa- From: Axel Rauschmayer Sent: Friday, January 06, 2012 12:11 PM To: Allen Wirfs-Brock Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in ... As a human, I would want an ES6 trigger to appear as early as possible. I wouldn’t want

Re: Improving Function.prototype.bind

unreachable without reference count? do you have an example different from a private scope object that is reachable from that scope so I would not call it unreachable? In any case I understand your leaks point and if WeakMap solves this, but I strongly believe no shim will be able to emulate this

Re: Improving Function.prototype.bind

Le 06/01/2012 12:23, Andrea Giammarchi a écrit : it doesn't ... as soon as you release the reference to o no leaks persists but of course until you keep o on hold those unique callbacks cannot be released ... If you're telling me that keeping only one of the object or the function alive but not

Re: Improving Function.prototype.bind

it doesn't ... as soon as you release the reference to o no leaks persists but of course until you keep o on hold those unique callbacks cannot be released ... but this would be true with WeakMap too, isn't it? In any case, boundTo is suitable for listeners and the whole point is to do not hold ma

Re: ES6 doesn't need opt-in

>> Ok, is there any observable difference between what you would have future >> browsers do, vs the equivalent mechanisms except that program #2 is >> categorized as an ES6 program and processed as such? >> >> If there is no observable difference, good. Then it's only a matter of how >> we desc

Re: Improving Function.prototype.bind

Le 06/01/2012 11:20, Andrea Giammarchi a écrit : On Fri, Jan 6, 2012 at 10:50 AM, David Bruant > wrote: Your proposal won't be implemented in older browsers. Actually, it is very likely that your proposal would be implemented in browsers that would alrea

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 10:50 AM, David Bruant wrote: > > Your proposal won't be implemented in older browsers. Actually, it is very > likely that your proposal would be implemented in browsers that would > already have weak maps. > Under these conditions. What is the benefit of a native implement

Re: Improving Function.prototype.bind

Le 06/01/2012 10:40, Andrea Giammarchi a écrit : if WeakMaps are so smart ... it means we cannot shim them without causing leaks in non WeakMap ready browsers since no magic will happen,objects as keys will simply be persistent in the WeakMap private scope Indeed. Also, Mark Miller mentionned a

Re: Improving Function.prototype.bind

that's pretty much what I have already written in my blog ... isn't it? The speed up is that "ghost" list of bound functions per object hard to properly manage, performances speaking, via pure JS It seems that at least you perfectly got what I am talking about, yeah :D br On Fri, Jan 6, 2012 at

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

For hash maps with string keys, people can concatenate the string keys with a random prefix. This fixes this attack, and also prevents the attacker from using annoying keys like __proto__, hasOwnProperty or toString. It doesn't fix things for JSON though, if you are reading untrusted (in the DOS

Re: Improving Function.prototype.bind

if WeakMaps are so smart ... it means we cannot shim them without causing leaks in non WeakMap ready browsers since no magic will happen, objects as keys will simply be persistent in the WeakMap private scope ... does not look good, means we cannot solve this via libraries, means my initial proposa

Re: Improving Function.prototype.bind

Le 06/01/2012 06:03, Mark S. Miller a écrit : 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

Re: Improving Function.prototype.bind

My proposal could break existing code so it’s probably not worth a shot in ES6. Maybe in ES7, then. From: Brendan Eich Sent: Friday, January 06, 2012 12:52 AM To: François REMY Cc: Axel Rauschmayer ; Andrea Giammarchi ; es-discuss Subject: Re: Improving Function.prototype.bind What *exactly*

Re: Improving Function.prototype.bind

Such an implementation would be very slow and not efficient, because searching for a key in the "boundFunctions" weakmap would take time. It can be a polyfill solution but a new implementation need something better. I think the solution would be to create an "invisible" [[boundFunctions]] prop

Re: Improving Function.prototype.bind

Le 05/01/2012 23:10, Andrea Giammarchi a écrit : leaks When a function has no strong reference, the associated entry in the first WeakMap (which is the second level of weakmap) can be GC'ed. When an object has no strong reference, all entries in second-level WeakMaps can be collected. I don't s

Re: Improving Function.prototype.bind

same thing this does var bound = Object.bind(Object); bound.foo = capabilityBobShouldntGet; // who does this ? var HAH = bound.foo; ... so I am missing your point I guess ... but my proposal wants to return always same object for 99.9% of usage out there ... On Fri, Jan 6, 2012 at 8:55 AM, Mark

Re: ES6 doesn't need opt-in

On Fri, Jan 6, 2012 at 12:24 AM, Allen Wirfs-Brock wrote: > > There should be no observable difference. But the issue isn't how we > described the (program) semantics. It is how we decide which semantics to > apply. > Got it. It still gives the web only two modes, but has the huge benefit that

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 12:00 AM, Mark S. Miller wrote: > On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock > wrote: >> >> 1) program using only ES3 features and no "use strict"; >> >> 2) program using only ES5 strict features and saying "use strict"; >> >> 3) program using ES6-only

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 10:38 PM, Luke Hoban wrote: > ... > # Why ‘implicit explicit opt-in’ doesn’t seem reasonable # > > The prevalent alternatives presented in this thread are variations of > “implicit explicit opt-in”, where use of some new syntax causes some part of > the code inside or outs

Re: ES6 doesn't need opt-in

On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock wrote: > > 1) program using only ES3 features and no "use strict"; > > 2) program using only ES5 strict features and saying "use strict"; > > 3) program using ES6-only features. > > Do these three programs operate in three different mo