Re: Legitimate uses of IIFEs?

[Mat At Bread]

Which is what I said, I hope. Use the .then for top-level invitation. 
Dimitry's example wouldn't resolve the Promise



On 19 December 2015 9:24:04 pm Fabrício Matté  wrote:


@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
  })().then(v => cb(null, v), cb);
}
```

/fm

On Sat, Dec 19, 2015 at 7:11 PM,  wrote:


That’s not going to work. The correct form still requires an (illegal)
top-level await:

await (async function() {
// await here
})();

The easiest way to spawn a top-level async function is:

here.then(function(result){},function(error){}) ;

On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov <
dmitry.soshni...@gmail.com> wrote:



On Saturday, December 19, 2015, Šime Vidas  wrote:

With block statements + let/const, IIFEs are no longer needed to emulate
block-scoped variables. That got me thinking, are there other uses of
IIFEs, or are they no longer needed?
I’ve checked my code and found instances of this pattern:

var foo = (function () {
var a, b, c; // helper variables
// some computation
return /* final value of foo */;
}());
Btw, there is a "do expression" proposal (stage 0) [1] for this type of
pattern.
Anything else?


FWIW, one of the still valid use cases is async IIFE, to spawn an async
code (since there's no yet top-level async/await)

(async function() {
  // await here
})();

Dmitry



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[bread]

That’s not going to work. The correct form still requires an (illegal) 
top-level await:

await (async function() {
// await here
})();

The easiest way to spawn a top-level async function is:

here.then(function(result){},function(error){}) ;

On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov 
 wrote:

> 
> 
> On Saturday, December 19, 2015, Šime Vidas <> wrote:
> 
> > With block statements + let/const, IIFEs are no longer needed to emulate 
> > block-scoped variables. That got me thinking, are there other uses of 
> > IIFEs, or are they no longer needed?
> > I’ve checked my code and found instances of this pattern:
> > 
> > var foo = (function () {
> > var a, b, c; // helper variables
> > // some computation
> > return /* final value of foo */;
> > 
> > }());
> > 
> > Btw, there is a "do expression" proposal (stage 0) [1] for this type of 
> > pattern.
> > Anything else?
> > 
> FWIW, one of the still valid use cases is async IIFE, to spawn an async code 
> (since there's no yet top-level async/await)
> 
> (async function() {
> // await here
> })();
> 
> Dmitry 
>

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Legitimate uses of IIFEs?

[Šime Vidas]

With block statements + let/const, IIFEs are no longer needed to emulate
block-scoped variables. That got me thinking, are there other uses of
IIFEs, or are they no longer needed?

I’ve checked my code and found instances of this pattern:

var foo = (function () {
var a, b, c; // helper variables
// some computation
return /* final value of foo */;
}());

Btw, there is a "do expression" proposal (stage 0) [1] for this type of
pattern.

Anything else?


[1]: https://github.com/tc39/ecma262/issues/132
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Fabrício Matté]

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 for real code you would write, seeing as ECMAScript modules are
implicitly strict and we should have do-expressions soon, I don't see much
use for IIFEs anymore.

/fm
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Fabrício Matté]

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 a more solid example

.

/fm
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Caitlin Potter]

Note that currently, you can't set the language mode in a do-expression. Of 
course that could change, i think they're wanting to change a bunch of other 
things already.

> On Dec 19, 2015, at 2:54 PM, Fabrício Matté  wrote:
> 
> 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 for real code you would write, seeing as ECMAScript modules are implicitly 
> strict and we should have do-expressions soon, I don't see much use for IIFEs 
> anymore.
> 
> /fm
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Dmitry Soshnikov]

On Saturday, December 19, 2015, Šime Vidas  wrote:

> With block statements + let/const, IIFEs are no longer needed to emulate
> block-scoped variables. That got me thinking, are there other uses of
> IIFEs, or are they no longer needed?
>
> I’ve checked my code and found instances of this pattern:
>
> var foo = (function () {
> var a, b, c; // helper variables
> // some computation
> return /* final value of foo */;
> }());
>
> Btw, there is a "do expression" proposal (stage 0) [1] for this type of
> pattern.
>
> Anything else?
>

FWIW, one of the still valid use cases is async IIFE, to spawn an async
code (since there's no yet top-level async/await)

(async function() {
  // await here
})();

Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Fabrício Matté]

@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
  })().then(v => cb(null, v), cb);
}
```

/fm

On Sat, Dec 19, 2015 at 7:11 PM,  wrote:

> That’s not going to work. The correct form still requires an (illegal)
> top-level await:
>
> await (async function() {
> // await here
> })();
>
> The easiest way to spawn a top-level async function is:
>
> here.then(function(result){},function(error){}) ;
>
> On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov <
> dmitry.soshni...@gmail.com> wrote:
>
>
>
> On Saturday, December 19, 2015, Šime Vidas  wrote:
>
> With block statements + let/const, IIFEs are no longer needed to emulate
> block-scoped variables. That got me thinking, are there other uses of
> IIFEs, or are they no longer needed?
> I’ve checked my code and found instances of this pattern:
>
> var foo = (function () {
> var a, b, c; // helper variables
> // some computation
> return /* final value of foo */;
> }());
> Btw, there is a "do expression" proposal (stage 0) [1] for this type of
> pattern.
> Anything else?
>
>
> FWIW, one of the still valid use cases is async IIFE, to spawn an async
> code (since there's no yet top-level async/await)
>
> (async function() {
>   // await here
> })();
>
> Dmitry
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[bread]

I believe await* has gone from the spec. The correct form would be (at the 
top-level):

```js


Promise.all(asyncFn1(...), asyncFn2(...),...).then(...)
```


The mistake in Dimitry's example is that the async body was not resolved, not 
that anonymous async functions are in some way invalid - they're just fine.
On 19 December 2015 20:47:57 -00:00, Fabrício Matté  wrote:

> 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 a more solid example 
> .
>
> /fm
>

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Fabrício Matté]

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* []`
would desugar to `await Promise.all([])`.


> The mistake in Dimitry's example is that the async body was not resolved,
> not that anonymous async functions are in some way invalid - they're just
> fine.
>

I'm not sure if I understand what you mean. I see that the outer
synchronous function would not await until the async function finished—i.e.
the outer function would return before the promise was resolved/settled—,
but that is still valid syntax—you could be running the async code for
side-effects that the caller context does not need to be aware of. You
mentioned this was invalid syntax, and that was the initial point I
addressed. :)

/fm
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Isiah Meadows]

One use case is where try-catch statements are required. I've had plenty of
these, and it's either declare the variable ahead of time, or wrap in a
IIFE.

Another use case: early returns and complex logic. This is pretty nice when
you're working with a complex set of conditions for a polyfill. I came
across this conditionally spawning a worker with a static implementation,
which included complex logic, early returns, and try-catch. Only the return
value was needed in the outer scope, so an IIFE simplified it.

```js
;(() => {
  if (window.somethingSimple) {
return somethingSimple(foo, bar)
  }

  let res

  // super complex workaround by necessity

  return res
})()
```

On Sat, Dec 19, 2015, 17:46 Fabrício Matté  wrote:

> 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* []`
> would desugar to `await Promise.all([])`.
>
>
>> The mistake in Dimitry's example is that the async body was not resolved,
>> not that anonymous async functions are in some way invalid - they're just
>> fine.
>>
>
> I'm not sure if I understand what you mean. I see that the outer
> synchronous function would not await until the async function finished—i.e.
> the outer function would return before the promise was resolved/settled—,
> but that is still valid syntax—you could be running the async code for
> side-effects that the caller context does not need to be aware of. You
> mentioned this was invalid syntax, and that was the initial point I
> addressed. :)
>
> /fm
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Brendan Eich]

Hi Rick, thanks to you and Mike for drafting. I will read and comment more
when I have time, but I wanted to channel the Twitter-ghost of Dave Herman:

"we should start from pattern matching and work our way from there into the
kinds of datatypes we want to match on"

I hear wycats and bterlson are working on pattern matching. Ccing them.

/be

On Thu, Dec 17, 2015 at 1:42 PM Rick Waldron  wrote:

> On Thu, Dec 17, 2015 at 3:33 PM Steve Kinney 
> wrote:
>
>> I did some initial thinking about this and looked at Rust and Swift as
>> prior art. I started something similar to what was being discussed but came
>> across some edge cases as I went along.
>>
>> https://github.com/stevekinney/ecmascript-enumerations
>>
>> Right now, it's just a draft of notes and thoughts, but I am working on a
>> draft implementation with Sweet.js.
>>
>
> I had originally had values with implicit ordinal numbers, but Mike
> Pennisi (co-author) and I agreed that with Symbol there isn't much benefit
> to making the raw value a number.
>
> Anyway, this is the WIP http://rwaldron.github.io/enum-definitions/
>
>
> Rick
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss