Re: Pseudo headless arrows

gt; On Apr 21, 2016 3:34 PM, "Fabrício Matté" <ultco...@gmail.com> wrote: > > The `==>` token would look like a new operator, which developers would > have to look up in order to know exactly what it does. It is more confusing > than helpful, IMHO. > Also `==>x`

Re: Pseudo headless arrows

The `==>` token would look like a new operator, which developers would have to look up in order to know exactly what it does. It is more confusing than helpful, IMHO. Also `==>x` has the same length as `_=>x`, the latter not introducing any new syntax (although it does employ an ugly unused

Re: [ small request - Javascript for javaing]

On Fri, Jan 1, 2016 at 3:47 PM, Herby Vojčík wrote: > Maybe we should rename the colloquial name of the language, to give clear > signal to this kind of Javaist that Java should not have been there at > first place and JS is something else. To retain .js extension it should be

Re: Legitimate uses of IIFEs?

On Sun, Dec 20, 2015 at 8:39 PM, Bergi wrote: > I've never heard of an "Arrow function expression" - it's just "arrow > function" :-) It is true that the current spec. always refers to the production as "ArrowFunction". Though, there are threads proposing Arrow Function

Re: Legitimate uses of IIFEs?

On Sun, Dec 20, 2015 at 7:32 PM, wrote: > there is no reason to create an async function to invoke another async > function; one can simply invoke it, and if the result/completion is > required, use it's ,then() memberbut there's no need/advantage to > wrapping such an

Re: Legitimate uses of IIFEs?

You can use II(A)FE to summon strict mode in sloppy contexts (such as Chrome's DevTools console): ```js (() => { 'use strict'; // ... })(); ``` This is useful as Chrome either does not implement or uses legacy semantics for quite a few ES2015 features in sloppy mode (e.g. let, const). As

Re: Legitimate uses of IIFEs?

Good call, Dmitry. Async IIFEs are also useful to parallelize different sequences of async operations. E.g.: ```js async function main() { await* [ (async () => await seq1op2(await seq1op1()))(), (async () => { await seq2op1(); await seq2op2(); })(), ]; } ``` Here is

Re: Legitimate uses of IIFEs?

@bread I see you are referencing Dmitry's sample, but why do you say it won't work? AFAIK async functions return promises, so you don't necessarily need a top-level `await`. I believe this (extremely ugly) sample should work: ```js function f(cb) { (async function() { // await here

Re: Legitimate uses of IIFEs?

On Sat, Dec 19, 2015 at 8:10 PM, wrote: > I believe await* has gone from the spec. The correct form would be (at the > top-level): > True, I guess `await*` never made it to the proposal's formal text. It still worked in Babel the last time I checked, though. FWIW, `await*

Re: Exponentiation operator precedence

You don't need to be a language guru to know which operation will be performed first, you can (and should) check an operator precedence and associativity table such as MDN's https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence . Knowing operator

Re: Static local variables

What you've described seems very similar to PHP's static variables http://php.net/manual/en/language.variables.scope.php#language.variables.scope.static. They are very nice syntactic sugar, in my opinion. I'm just not sure if this is worth adding new syntax to the language, as there is already a

Re: Module import/export bindings

Regarding the internal server error, see https://github.com/esdiscuss/esdiscuss.org/issues/83#issuecomment-59661326 /fm ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: A Declarative replacement for toMethod

``` PostfixExpression : [...] MixinExpression [no LineTerminator here] ++ MixinExpression [no LineTerminator here] -- ``` Is this a typo? What is the point of the `++`/`--` postfix operators after a `MixinExpression`? /fm ___ es-discuss

Re: A Declarative replacement for toMethod

It's establishing the precedence of the MixinExpression between PostfixExpression and LeftHandSideExpression. Thanks Kevin, I thought it could be the case, but I still can't see when that is relevant -- as far as I can see, the resulting value of a mixinExpression is always an object (or a

Re: Rev32 ES6 draft now available

So much awesomeness in this revision, congratz TC39! /fm ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: es-discuss Digest, Vol 95, Issue 45

Point 2 is incorrect (e.g. `new (Foo.bind.apply(Foo, [undefined].concat(args)))`). I stand corrected. That's very good news, thanks! Nice and elegant solution, by the way. I should have taken the time to look at how current transpilers handle that. Your solution is similar to Traceur's

Re: Array.prototype.contains solutions

I faintly remember seeing a sort of proposal containing many different approaches as how to solve this generic built-ins extensions problem in future editions of ECMAScript. I believe it was authored by Domenic Denicola, in Gist/GitHub format if memory serves me right. I can't seem to find it,

Re: Array.prototype.contains solutions

https://www.google.com/search?q=site%3Aesdiscuss.org+Array.prototype.contains+solutions leads to https://esdiscuss.org/topic/array-prototype-contains-solutions which is probably what you were thinking of. They were not very good ideas. For some reason I thought you had evolved those ideas

Fwd: es-discuss Digest, Vol 95, Issue 45

In that case, we can expect that users will want to implement factory when called as a default behavior for their classes. From that, we can foresee that the following pattern: if (!new.target) return new Whatever(...args); will become a kind of boilerplate. Obviously, we want to

Re: es-discuss Digest, Vol 95, Issue 45

Your second example may break if the constructor is called via `.call()`/`.apply()` or as a *CallExpression : MemberExpression* or if it has been `.bind()`ed. Although these may look like corner cases, a good transform should cover these cases, especially *CallExpression : MemberExpression* as it

Re: A new ES6 draft is available

I agree with Frankie. Assume a developer who has never seen this `new.target` construct before. They will first think that this is an invalid expression, as `new` is an operator. Then, upon seeing this code execute, the natural question is What is `new`? Is it an identifier injected into

Re: A new ES6 draft is available

For a short term solution, I would suggest `arguments.new.target`. The `arguments` object already contains info about how the function was called (its arguments, the deprecated/obsolete `callee` and obsolete/never-spec'd `caller` properties), so adding information about how the function was called

Re: A new ES6 draft is available

Currently in ES6, the only reserved keywords that can appear immediately before a `.` are `this` and `super`. The `this` binding resolves to a value, so MemberExpressions make sense. The `super` keyword is being implemented in ES6, so there are no precedents to set expectations. Any other

Re: A new ES6 draft is available

Oh thanks! I just got a copy of the draft rev 31 to check it out. Meta properties sounds like a good name to me. Also, JavaScript meta properties does not have significantly relevant search results, so it should be easy to google for in the future. /fm

Re: Promise rejections don't resolve the argument

`Promise.resolve` and the Promise executor function's `resolve` argument lets you delegate the fulfillment of the given promise to another promise object. That is essential for composability. In the other hand, `Promise.reject` and the Promise executor function's `reject` argument are to be

Re: Promise rejections don't resolve the argument

*By any object I mean any value. Anyway, it would be interesting to see a real use case for passing a promise as reject reason. /FM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Promise rejections don't resolve the argument

Yes, delegating to another promise which then rejects should cover that use case. `=]` /FM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Weak{Map,Set}.p.clear() implementation proposal

Nice idea, but there seems to be (some) complications. Set **this** to *T*. What is `this` specifically? As far as I can see, it is a value and not a reference. And even if it were a reference, setting it to point to another object does not affect the other references which point to the old

Fwd: Weak{Map,Set}.p.clear() implementation proposal

What I mean is, consider this code: ```js var wsRef = new WeakSet(); var wsRef2 = wsRef; wsRef.clear(); ``` As far as I can see, in the `wsRef.clear()` algorithm, the `this` value has no relation with the `wsRef` identifier. Even if there was some internal magic around changing the identifier's

Re: Weak{Map,Set}.p.clear() implementation proposal

​ Not in pure ECMAScript being interpreted, but it can definitely be done in the implementation. Yeah I think so too, but if no where else in the specification uses this pattern, implementations would be required to implement new mechanisms and possibly have de-optimizations.

Re: Weak{Map,Set}.p.clear() implementation proposal

I understand that objects are passed by reference in Java (similarly to ECMAScript), however I'm not sure how implementations link Lexical Environments' identifiers to their respective values, and re-mapping these would be more complicated than the C++ sample you've posted I believe.​ As far as I

Re: Array.prototype.values is not web compat (even with unscopables)

@Benjamin Not sure if I understand what you mean. If standards don't dictate, then how are we supposed to expect interoperable implementations? By impossible I suspect you mean something that browser vendors should never do. I understand back-compatibility with the Web is a must for browser

Re: Array.prototype.values is not web compat (even with unscopables)

Here is a related Twitter discussion: https://twitter.com/domenic/status/523202298466418688 To highlight the main points: Domenic Denicola claims that extending built-in prototypes is not web-compatible. Indeed, if we consider all possible corner-cases and ignore best practices (which is often