ES6 problem with private name objects syntax

2014-01-08 Thread Maciej Jaros
To my understanding private name objects are supposed to make private properties and functions available for new classes syntax in ECMAScript 6 standard. But the syntax is rather strange: ``` var myPrivate = new Name(); class Test { constructor(foo) { this[myPrivate] = foo;

Re: const VS features detection

2014-01-08 Thread Andreas Rossberg
On 7 January 2014 20:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Unless we can identify real implementation issues, the semantics of do { } should simply be those of a blocks. I don't think this flies anyway. It has to be more like a function body, otherwise var and function

Re: ES6 problem with private name objects syntax

2014-01-08 Thread David Bruant
Hi Maciej, Le 08/01/2014 09:59, Maciej Jaros a écrit : To my understanding private name objects Note that now their name is symbol and not private name anymore. are supposed to make private properties and functions available for new classes syntax in ECMAScript 6 standard. A private keyword

const VS features detection

2014-01-08 Thread Kevin Smith
Since do-as-IIFE carries with it a subset of the semantics carried by do--as-block, I think it makes sense to proceed with the subset first, and expand if do-as-IIFE turns out to be surprising or lacking. IIUC, the goal here is to allow a sequence of statements to produce a value, not

Re: const VS features detection

2014-01-08 Thread Mark S. Miller
If all you want is a non verbose IIFE, use an arrow function. We should consider do expressions only if they avoid the TCP violations of strict arrow IIFEs. On Wed, Jan 8, 2014 at 6:51 AM, Kevin Smith zenpars...@gmail.com wrote: Since do-as-IIFE carries with it a subset of the semantics

Re: const VS features detection

2014-01-08 Thread Mark S. Miller
On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg rossb...@google.comwrote: On 7 January 2014 20:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Unless we can identify real implementation issues, the semantics of do { } should simply be those of a blocks. I don't think this flies

Re: const VS features detection

2014-01-08 Thread Andrea Giammarchi
arrow function works by accident better than just function thanks to its trapped context. Still bugs me by design we need to create garbage, including one-shot functions, in order to inline a try/catch to assign to a single pointer ```javascript const ES6_PROXY = ()={ try { new

Re: const VS features detection

2014-01-08 Thread Allen Wirfs-Brock
On Jan 8, 2014, at 8:32 AM, Mark S. Miller wrote: If all we want is sugar for IIFEs, I wouldn't bother. With arrow functions, IIFEs are already a lot shorter. The extra brevity of do expressions is not worth it. What would make do expressions worthy of consideration is if they repaired

RE: const VS features detection

2014-01-08 Thread François REMY
Please note that you do not really create a one-shot function and garbage in this case, at least if the compiler does his job well. The F# compiler, and probably many functional language compilers, would correctly inline the lambda function here. There’s probably no reason a JavaScript

Re: const VS features detection

2014-01-08 Thread Andrea Giammarchi
I still need to think in terms of creating garbage ... being unaware of optimizations behind the scene. I like to believe compilers should help optimizing for me instead of me developing to simplify compilers job so despite how complicated would be behind the scene I meant a `do { try/catch }`

Re: const VS features detection

2014-01-08 Thread Kevin Smith
If all you want is a non verbose IIFE, use an arrow function. We should consider do expressions only if they avoid the TCP violations of strict arrow IIFEs. One could say that they are verbose: var x = (_= { /* some statements, with a return statement somewhere */ })(); vs. var x =

generators inside DOM events

2014-01-08 Thread Andrea Giammarchi
I am not sure this has been discussed already but I wonder what would happen if `yield` is used inside an event such 'beforeunload', 'unload', or even 'click' and others DOM related events. Main concerns: 1. it's a UA trap potentially making impossible to leave a page or complete a user

RE: generators inside DOM events

2014-01-08 Thread Domenic Denicola
What? That would just cause the event handler function to return a generator object, which the browser would not use or do anything with. It would have no effect. From: es-discuss es-discuss-boun...@mozilla.org on behalf of Andrea Giammarchi

Re: generators inside DOM events

2014-01-08 Thread Andrea Giammarchi
Sorry, I explained it badly ... let me try again: what if a DOM event handler uses/creates/invokes inside its function body a generator? Will the event pause until this will be satisfied? `a.addEventListener('click', function(e){ if(methodThatInvokesGenerator()) e.stopPropagation(); });` Is

Re: generators inside DOM events

2014-01-08 Thread Brandon Benvie
On 1/8/2014 1:05 PM, Andrea Giammarchi wrote: Sorry, I explained it badly ... let me try again: what if a DOM event handler uses/creates/invokes inside its function body a generator? Will the event pause until this will be satisfied? `a.addEventListener('click', function(e){

Re: generators inside DOM events

2014-01-08 Thread Andrea Giammarchi
OK, I have overlooked at this ... so the following code won't have any side effect, correct? ```javascript addEventListener('beforeunload', function (e) { (function*() { while (true) yield null; }()); }); ``` Thanks On Wed, Jan 8, 2014 at 1:12 PM, Brandon Benvie bben...@mozilla.com

Re: generators inside DOM events

2014-01-08 Thread Andrea Giammarchi
sorry, actually the right example was with `while (true) yield evt;` but that's the same of async callback, the event is gone. Well, everything good then ^_^ Thanks again On Wed, Jan 8, 2014 at 1:19 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: OK, I have overlooked at this ...

Re: ES6 problem with private name objects syntax

2014-01-08 Thread Rick Waldron
On Wed, Jan 8, 2014 at 3:59 AM, Maciej Jaros e...@wp.pl wrote: To my understanding private name objects are supposed to make private properties and functions available for new classes syntax in ECMAScript 6 standard. But the syntax is rather strange: ``` var myPrivate = new Name(); class

Re: Additional Set.prototype methods

2014-01-08 Thread Calvin Metcalf
specific to set (as opposed to ones that work with array) would be the mathematical set operations like union, symmetrical difference (think xor), compliment, and intersection. On Fri, Jan 3, 2014 at 12:52 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Dec 31, 2013 at 11:36 AM, David

Behavior of `eval` in non strict mode.

2014-01-08 Thread Benjamin (Inglor) Gruenbaum
I've recently run into this question in Stack Overflow: http://stackoverflow.com/q/21008329/1348195 ``` function f() { f = eval( + f); console.log(Inside a call to f(), f is: \n%s, f);} f(); console.log(After a call to f(), f is: \n%s, f); ``` What should the output of the following

Re: Behavior of `eval` in non strict mode.

2014-01-08 Thread Andrea Giammarchi
looks rather an eval gotcha but I think Firefox is correct anyway. try `f = eval(( + f + ));` instead and it should produce what you expect (I guess) Regards On Wed, Jan 8, 2014 at 3:37 PM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: I've recently run into this question in Stack

Re: Behavior of `eval` in non strict mode.

2014-01-08 Thread Benjamin (Inglor) Gruenbaum
Thanks for the reply. I'd actually expect `undefined` because function declarations does not return anything. Converting it to a function expression kind of misses the point since those are well... expressions :) I've tried looking in all the relevant places in the spec but still couldn't

Re: Behavior of `eval` in non strict mode.

2014-01-08 Thread Andrea Giammarchi
I think eval returns whatever it evaluates ... i.e. `var x = eval('123');` x will be 123 since it's returned. Accordingly, if you assign a function, this should be returned and become automatically an expression. The inconsistency exists using explicitly parenthesis but I don't remember specs

Re: Additional Set.prototype methods

2014-01-08 Thread Erik Arvidsson
I always envisioned that we would create a full fledged iter module and then we would define these functions once and for all. On Jan 8, 2014 6:32 PM, Calvin Metcalf calvin.metc...@gmail.com wrote: specific to set (as opposed to ones that work with array) would be the mathematical set

Re: Behavior of `eval` in non strict mode.

2014-01-08 Thread André Bargull
Thanks for the reply. I'd actually expect `undefined` because function declarations does not return anything. Converting it to a function expression kind of misses the point since those are well... expressions :) I've tried looking in all the relevant places in the spec but still couldn't