RE: Observable GC

[Domenic Denicola]

https://w3ctag.github.io/design-principles/#js-gc

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Michal 
Wadas
Sent: Friday, October 20, 2017 08:07
To: es-discuss@mozilla.org
Subject: Observable GC

Hi.
Is there any comprehensive answer about why ability to observe garbage 
collection is considered undesirable in JavaScript?
Michał Wadas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Stream + async await

[Domenic Denicola]

That is not why.



From: Jan-Ivar Bruaroey 
Sent: Aug 1, 2017 3:47 PM
To: es-discuss@mozilla.org
Subject: Re: Stream + async await

Because a promise is not a control surface of the asynchronous action 
fulfilling it; confuses owner with consumer. 
https://stackoverflow.com/a/41417429/918910

.: Jan-Ivar :.

On 7/31/17 7:35 AM, T.J. Crowder wrote:
Related: https://esdiscuss.org/topic/how-about-awaiting-arrays (particularly 
the discussion of `await.race`), since effectively you're doing a race between 
a timeout and each chunk. Also relevant is the former work on cancelling 
promises, now withdrawn. (Can anyone point me at *why* it was withdrawn?)

-- T.J. Crowder

On Mon, Jul 31, 2017 at 6:10 AM, kai zhu 
> wrote:
the timeout handler will not work as advertised, e.g. what if io / db issues 
causes a network stream to intermittently respond in intervals far greater than 
3ms or not at all?

> On Jul 31, 2017, at 7:26 AM, James Browning 
> > wrote:
>
> It'll look something like this:
>
> ```javascript
>
> async function consumeReadableStream(stream) {
> const start = Date.now()
> for await (const chunk of stream) {
>
>/* Do whatever you want with the chunk here e,g, await other
> async tasks with chunks
>send them off to wherever, etc
>*/
>
> if (Date.now() - start > 3) {
> throw new Error('3 ms timeout')
>}
>}
>/* Instead of callbackOnce the returned promise from this function
> itself can be used */
> }
>
> ```
> ___
> 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




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



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

RE: Stream + async await

[Domenic Denicola]

https://github.com/tc39/proposal-async-iteration

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Naveen 
Chawla
Sent: Tuesday, July 11, 2017 09:24
To: es-discuss@mozilla.org
Subject: Stream + async await

It'd be great to have async stream constructs such as: 
http://reactivex.io/rxjs/ , supported natively, such that they can be used 
directly with the async / await keywords for async stream programming in a 
linear fashion (analogous to what can already be done with linearly awaiting 
Promises, but for async streams instead).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Naming convention for multi-word identifiers with initialisms

[Domenic Denicola]

https://w3ctag.github.io/design-principles/#casing-rules

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Alexander 
Jones
Sent: Tuesday, July 11, 2017 08:07
To: es-discuss@mozilla.org
Subject: Naming convention for multi-word identifiers with initialisms

Occasionally this comes up when deciding on a spelling for something. There are 
numerous examples in ECMAScript and other Web standards that seem to defy the 
most uniform convention:

 * `JSON` vs. `Json`
 * `toJSON` vs. `toJson`
 * `XMLHttpRequest` vs. `XmlHttpRequest`
 * `DOMElement` vs. `DomElement`

While it looks initially strange to specifically drop the capital letters on an 
initialisms like XML, the rule is simple in that it has an obvious machine 
decoding - a capital letter starts a new word. Thus, translations of 
identifiers to other case conventions are automatic (so long as numbers never 
appear at the start of a word). This helps a lot when e.g. generating bindings 
for IDLs to different languages, or in general interfacing different systems 
that really, really want to use their own naming conventions.

 * mixed case: `myTlaIdentifierHere`
 * pascal case: `MyTlaIdentifierHere`
 * underscore case: `my_tla_identifier_here`
 * uppercase: `MY_TLA_IDENTIFIER_HERE`
 * kebab case: `my-tla-identifier-here`
 * spaces case: `my tla identifier here`

---

My question is whether there is an existing community recommendation anywhere 
for naming ECMAScript identifiers. Clearly, when Microsoft devised the name 
`XMLHttpRequest`, someone was having a difficult time figuring out how to spell 
adjacent initialisms in PascalCase.

If there is no recommendation, perhaps there should be? Is there any scope for 
non-normative sections of information like this in the ECMAScript spec?

Thanks

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

RE: Microtask scheduling

[Domenic Denicola]

The work has since moved into the specification that defines the event loop, 
i.e. the HTML Standard:


  *   https://github.com/whatwg/html/issues/512
  *   https://github.com/whatwg/html/pull/2789


From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Isiah 
Meadows
Sent: Tuesday, June 27, 2017 16:25
To: Calvin Metcalf ; C. Scott Ananian 

Cc: es-discuss@mozilla.org
Subject: Re: Microtask scheduling

I was browsing and stumbled on a strawman that is nearly identical to what I 
proposed here (mod the extra args handling), just a couple years old:

https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#510-globalasap-for-enqueuing-a-microtask

On Mon, Jun 26, 2017, 13:49 Calvin Metcalf 
> wrote:
One of the big use cases for process.nextTick is throwing errors outside the 
current stack, either to avoid preventing cleanup or to avoid being caught in 
try/catch blocks or promise chains so using a promise directly isn't very 
useful.  This came up in the browserify/webpack shim for process.nextTick

On Mon, Jun 26, 2017 at 12:29 PM C. Scott Ananian 
> wrote:
Promise dispatch should actually simplify to this in certain common cases.  I 
meant to write up a document describing the typical dispatch optimizations 
high-performance Promise libraries do, based on my experiences writing 
https://github.com/cscott/babybird (although Optimization Notes in the README 
of that package contains the basic details).  Assuming the Promise 
implementation is fast, then Promise#then0(...) should basically give you 
direct access to the internal `asap`-like dispatcher.
  --scott

On Mon, Jun 26, 2017 at 8:20 AM, Calvin Metcalf 
> wrote:
Kris, you're conflating macrotasks and microtasks [1]. This has come up a 
couple times before and there have been issues raised by browser venders[2][3].


1. https://github.com/YuzuJS/setImmediate#macrotasks-and-microtasks
2. https://bugzilla.mozilla.org/show_bug.cgi?id=686201
3. 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Hn3GxRLXmR0/XP9xcY_gBPQJ

On Mon, Jun 26, 2017 at 2:51 AM Kris Siegel 
> wrote:
This seems more like a platform-level feature versus something that needs to be 
part of the ECMAScript standard. Also, keep in mind it's rarely a good idea to 
explicitly call nextTick() in node as it executes the code immediately after 
the current code is finished and before the next, scheduled code (this can 
cause issues with processing I/O if you're doing it too frequently).

In a browser you can sorta emulate similar behavior through IE's 
setImmediate(), using postMessage() or even the requestAnimationFrame(). 
Granted none of those are exactly like nextTick() and I wouldn't mind seeing 
something like setImmediate() become more of a standard but this isn't for the 
ECMAScript group.

On Wed, Jun 21, 2017 at 2:10 PM, Isiah Meadows 
> wrote:
It's a relatively low-level operation, but in performance-sensitive
async code and polyfills, there's still a strong need for raw
microtask scheduling, at a much lower level than promises. In
particular, there's two very frequently used modules providing a
wrapper for this specific thing:

1. next-tick: A browser polyfill for Node's `process.nextTick`, with
over 2M downloads last month and 88 direct dependents.
2. asap: A microtask scheduler that avoids blocking Node's I/O loop,
with over 7M downloads last month and 88 direct dependents.

In addition, several libraries like Bluebird have to implement their
own wrappers to gain similar functionality without assuming another
dependency.

Any chance something like Node's `process.nextTick` could be added,
maybe something like `Promise.schedule(func, thisArg, ...args)`?

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
___
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

___
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: Are thrown errors in a try block considered to be handled even if there's no catch block?

[Domenic Denicola]

Indeed, you cannot replicate dispatchEvent’s behavior, because it catches the 
error, then uses a browser-specific primitive “report an exception”. Over in 
the HTML spec, we’ve suggested exposing that primitive to users, but it hasn’t 
garnered sufficient implementer interest; see 
https://github.com/whatwg/html/pull/1196.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of T.J. 
Crowder
Sent: Friday, June 23, 2017 07:01
To: Andy Earnshaw 
Cc: es-discuss 
Subject: Re: Are thrown errors in a try block considered to be handled even if 
there's no catch block?

> Are thrown errors in a try block considered to be handled
> even if there's no catch block?

An exception propagates out of a function (and thus is ultimately reported 
unhandled if unhandled) if it's what terminates the function. If code in the 
`finally` block does something to prevent the original exception terminating 
the function (by continuing a loop within the function, returning something, 
throwing a different exception, etc.), then the (original) exception doesn't 
propagate.

> If you swap out the catch block for a finally block (with either
> `continue` or some kind of recursive iteration), the errors
> aren't technically handled, but only that last one is
> considered "uncaught".

The last one will only be special if you treat it differently from the previous 
ones. I *think* you mean something like this:

```js
for (let i = 0; i < 3; ++i) {
try {
throw i; // E.g., code that may throw
} finally {
if (i < 2) { // If we're not on the last iteration
continue;
}
}
}
```

There, by using `continue` in the `finally` block (for all but the last one), 
we're preventing the exception from propagating because we've changed the 
completion of the block from 'throw' to 'continue', details:

* [The `continue` statement - Runtime semantics - Evaluation][1]
* [The `try` statement - Runtime semantics - Evaluation][2]
* and the various loop definitions, for instance [The `for` statement - Runtime 
semantics - ForBodyEvaluation][3].

I think that's the answer to your question about `finally`.

The core issue you're having, replicating `dispatchEvent`'s behavior, is 
fascinating; I don't think you can do what it does (at least, what it does on 
Chrome), because it calls the handlers *synchronously*, allowing their 
exceptions to propagate (synchronously), but also continuing its synchronous 
loop through the handlers. I found the results of this code fascinating, for 
instance (https://jsfiddle.net/krdqo1kw/):

```js
Promise.resolve().then(_ => console.log("then"));
const target = document.createElement('div');
target.addEventListener('foo', e => {
console.log("1");
throw 1;
});
target.addEventListener('foo', e => {
console.log("2; cancelling");
e.stopImmediatePropagation();
throw 2;
});
target.addEventListener('foo', e => {
console.log("3");
throw 3;
});
target.dispatchEvent(new CustomEvent('foo', {cancelable: true}));
console.log("dispatch complete");
```

On Chrome, I get:

```
1
Uncaught 1
2; cancelling
Uncaught 2
dispatch complete
then
```

...where the uncaught exception traces point to the `throw` line in the 
relevant event handler. Very nice. Note the synchronous processing. I should 
dive into the source, but clearly it's creating a job and running it 
synchronously (or code to that effect), and since the exceptions aren't handled 
by anything in the job, they get reported as unhandled.

On Firefox, I get

```
1
2; cancelling
dispatch complete
then
uncaught exception: 1
uncaught exception: 2
```

...where the traces point to the `dispatchEvent` line. So it seems to store 
them up and then report them.

Replicating the Firefox behavior in your own `dispatchEvent` function is fairly 
doable: Catch the exceptions, store them, and then fire them off asynchronously 
when done (https://jsfiddle.net/gwwLkjmt/):

```js
class Publisher {
constructor() {
this.subscribers = new Set();
}
subscribe(f) {
this.subscribers.add(f);
}
trigger() {
const exceptions = [];
const event = {cancel: false};
for (const f of this.subscribers) {
try {
f(event);
} catch (e) {
exceptions.push(e);
}
if (event.cancel) {
break;
}
}
for (const e of exceptions) {
setTimeout(_ => { throw e; }, 0);
}
}
}
const target = new Publisher();
target.subscribe(e => {
console.log("1");
throw 1;
});
target.subscribe(e => {
console.log("2; cancelling");
e.cancel = true;
throw 2;
});
target.subscribe(e => {
console.log("3");
throw 3;
});
target.trigger();
Promise.resolve().then(_ => console.log("then"));
```

On Chrome, those traces point to our `setTimeout` line; on Firefox, they don't 
have a source. Not really ideal 

Re: Intercepting sets on array-like objects

[Domenic Denicola]

I'm not really sure how you're expecting to get an answer "according to TC39." 
One member had replied and given his suggestion. I don't think it's a good one 
for new APIs; I think new APIs should use arrays and not type check on sets but 
at processing time. I'm sure there will be many other opinions from other TC39 
members.



From: "Tab Atkins Jr." 
Sent: Jun 9, 2017 5:02 PM
To: Adam Klein
Cc: es-discuss
Subject: Re: Intercepting sets on array-like objects

On Fri, Jun 9, 2017 at 1:57 PM, Adam Klein  wrote:
> On Thu, Jun 8, 2017 at 11:32 AM, Tab Atkins Jr. 
> wrote:
>> Note that if we don't get some variant of this functionality, these
>> APIs will instead do one of:
>>
>> * just using Proxies (already defined in WebIDL)
>
>
> When you say "Proxies" here, I believe you're referring to the "indexed
> properties" feature of WebIDL
> (https://heycam.github.io/webidl/#idl-indexed-properties). This seems like
> the right mechanism to use, from a WebIDL spec, to get the behavior you
> desire. In Chromium/V8, this doesn't actually use Proxies under the hood (we
> have something called "indexed property handlers", see the API at
> https://cs.chromium.org/chromium/src/v8/include/v8.h?rcl=ff98ddca4a1770c2868d44f1cdfe1d4656363f30=5781),
> but it's definitely implementable using Proxies.

Correct.

WebIDL's indexed getters/setters would fulfill my use-case *exactly*.
If that's okay to use, per TC39 consensus, then awesome!

However, in 
Anne says:

> [When] we discussed those kind of approaches with TC39, they told us not
> to and to just use Array. It wasn't just about [], it was also about FileList,
> NodeList, etc. And the problem with those was not that they did not have
> enough methods like Array, it was that they required a proxy.

Thus my confusion/consternation.

If this is incorrect, and indexed getters/setters are indeed fine to
use in new APIs, then we can close this thread "no change" and I can
go away happy. ^_^

~TJ
___
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: Unicode non-character being treat as space on Firefox/Chrome

[Domenic Denicola]

We should probably move this to a GitHub issue then, so ES can have clarity on 
it.


If it helps, I am pretty sure (although I should double-check) that HTML treats 
such noncharacters as conformance errors (i.e. external tools like validators 
will warn you about them), but does not let them impact the processing model; 
they are passed through as-is.


From: es-discuss  on behalf of Gareth Heyes 

Sent: Thursday, May 25, 2017 10:52:52 AM
To: Mark S. Miller
Cc: es-discuss@mozilla.org
Subject: Re: Unicode non-character being treat as space on Firefox/Chrome

On 25 May 2017 at 14:04, Mark S. Miller 
> wrote:
What is the relevant EcmaScript standards text that would delegate to this? 
Even if Unicode implies an undefined case, EcmaScript should not. If EcmaScript 
behavior for such cases is undefined, we should define it.

Looking at the spec. it seems undefined. 0xfffe isn't defined as a whitespace 
character. This is probably why we have different behaviour in different 
browsers.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Would it be possible to add “await on first use” to the language?

[Domenic Denicola]

We already have that feature in the language: it’s called await. Just rewrite 
the example like so, instead of using /* pause to await x */ comments:

async function makePizza(sauceType = 'red') {
  let dough  = makeDough();
  let sauce  = await makeSauce(sauceType);
  let cheese = grateCheese(sauce.determineCheese());
  
  dough = await dough;
  dough.add(sauce);
  dough.add(await cheese);
  
  return dough;
}

This way, instead of random punctuation like the "." operator causing your 
program to await... it's the actual await keyword.

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

Re: Cancel Token proposal withdrawl

[Domenic Denicola]

Why do you say "regarding performance"? That seems made up with no evidence.



From: Isiah Meadows 
Sent: Jan 5, 2017 20:09
To: es-discuss@mozilla.org
Subject: Cancel Token proposal withdrawl

The [latest proposal][1] has been withdrawn due to [Google
resistance][2] regarding performance. What concerns did they have, and
with what parts? It's hard to figure out what the problem is and come
up with ideas when it's all smoke and mirrors. And yes, I've tried
searching for any traces of an answer, but I've found pretty much
none, using multiple search engines.

Please, could I get some sort of idea what is actually wrong with the
proposal, what's driving them to be so strongly against it? :-(

[1]: https://github.com/tc39/proposal-cancelable-promises
[2]: 
https://github.com/tc39/proposal-cancelable-promises/issues/70#issuecomment-267414933

-

Isiah Meadows
m...@isiahmeadows.com
___
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: Object.equals() and Object.clone()

[Domenic Denicola]

The biggest problem with structured clone is that there’s no way to just invoke 
it directly. Doing so has been proposed a few times, most recently at 
https://github.com/whatwg/html/issues/793, but no implementers have expressed 
interest.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Kevin 
Barabash
Sent: Monday, November 14, 2016 23:51
To: Eric Devine 
Cc: es-discuss 
Subject: Re: Object.equals() and Object.clone()

I didn't know about structured clone so I looked it up.  It looks pretty 
promising.  As for checking if two things are equal, maybe it makes sense for 
objects to define their own `.equals(other)` methods.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm

On Mon, Nov 14, 2016 at 9:31 PM, Eric Devine 
> wrote:
How about beginning with the HTML structured clone algorithm, and a 
`Symbol.clone` property to allow an object to optionally define it's own 
cloning behavior?

On Mon, Nov 14, 2016 at 9:02 PM, Isiah Meadows 
> wrote:
I agree. Also, consider iterables. Should their `Symbol.iterator` method be 
called? There's no obvious behavior for the details, and people's opinions 
differ on what should be correct.

On Mon, Nov 14, 2016, 20:58 Frankie Bagnardi 
> wrote:
It's pretty hard to decide how these behave, specifically with custom classes. 
Focusing on Object.clone...

- with classes do you call the constructor, and with what arguments?
- HTMLElement and sub classes can't be constructed directly, what happens with 
them?
- do you copy internal properties? this would make it hard to polyfill
- how does it behave with getters and setters?
- with regular expressions do you copy the lastIndex?

Most of those apply to Object.equals also.



On Mon, Nov 14, 2016 at 6:25 PM, Kevin Barabash 
> wrote:
It would be nice if deep equality checking and deep cloning of objects was 
included in the standard library.  Has there been any proposals around 
including these in the past?

– Kevin


___
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

___
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: Endorse an unambiguous syntax for ES2015 modules

[Domenic Denicola]

From: martin heidegger [mailto:martin.heideg...@gmail.com] 

> Thank you for taking the time to answer. For some reason it seems like 
> I framed it to be a Node.js specific issue. In my understanding the current 
> ES2015 module specification is ambiguous regarding backwards compatibility.
> Node.js or Browser that surely is an issue for the implementers?! This 
> seems like a hole/bug/problem in the specification to me. (Please correct me 
> if I am wrong). And it also seems to me like this is a serious issue.

This is not correct. There is nothing backward-incompatible about adding a new 
top-level grammar goal. And the new grammar goal has even less impact on 
Node.js, which does not use the existing grammar goal that the spec gives them 
(Script).

It's true that there are source strings that match both the Script and Module 
goals. But this is not a problem for backward-compatibility, and calling it 
"ambiguous" is a stretch. (Is the string "Hello, world!" a text/plain or 
text/html file? It's "ambiguous", I guess, but no known software has problems 
with this "ambiguity".)

So the specific proposal of "unambiguous module grammar" is very much a Node.js 
specific issue. It's even worse than that: it's a Node.js specific issue where 
the proposal is to turn that Node.js specific issue into a restriction placed 
on all host environments, not just Node.js.

> This problem can be solved in my understanding either by adding out-of-band 
> metadata (file extension, mime-type, ...) or within the file ( shebang like 
> comments, "use strict" like spec etc.).

Yes, exactly. Browsers have chosen to solve this with out-of-band metadata 
(`import` only works on modules, not scripts, and 

RE: Endorse an unambiguous syntax for ES2015 modules

[Domenic Denicola]

From: Jordan Harband [mailto:ljh...@gmail.com] 

> An alternative answer to "What is the problem for the TC39 to doing the 
> endorse this effort?" is, it hasn't been presented to the committee yet. So, 
> it's a little soon to declare that there is or is not a consensus, or that 
> TC39 is doing or not doing anything about it. The committee hasn't been given 
> the chance to consider it yet.

Sure. But you can extrapolate from the many previous conversations with 
committee members about this proposal what will happen when it is presented. 
Similar to how if I planned to propose adding the C language's type system to 
JavaScript, it would be fair to make guesses about how such a proposal would 
go, and whether it would achieve consensus, based on previously-expressed 
opinions by committee members about types in JavaScript.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Endorse an unambiguous syntax for ES2015 modules

[Domenic Denicola]

As has been discussed many times, TC39 doesn’t need to endorse Node placing 
host-environment-specific restrictions on its inputs. They already impose 
restriction that CJS modules be FunctionBody, instead of the top-level Script 
production in the spec. Similarly, they can create their own grammar 
production, ModuleWithRequiredImportOrExport (or whatever), and impose that on 
their users as a second alternate restriction.

What many people in TC39 will not support is placing an unnecessary restriction 
on all users of JavaScript. That is against the goal of our job as a 
host-environment-agnostic language. We supply the building blocks, and 
different host environments do different things with those. E.g. HTML has a 
nonstandard entry point for inline event handlers (onload=""), but we don’t 
codify that restriction into the language in some way; that’s just not our job 
and would be counterproductive to environments like Node which don’t need to 
support inline event handlers.

Furthermore, at least several members of TC39 see a file extension as a 
tried-and-true way of communication out of band metadata, and think that’s a 
fine way to go. There are other possibilities, e.g. using import for ES modules 
and require for CommonJS ones (along with a command-line switch for the entry 
module). So even if you’re talking about endorsing Node.js requiring 
ModuleWithRequiredImportOrExport for their users, I don’t think you’ll find a 
consensus among TC39 to “endorse” such an approach, since several members think 
it’s a less elegant solution than other possibilities.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of martin 
heidegger
Sent: Tuesday, September 6, 2016 23:17
To: es-discuss@mozilla.org
Subject: Endorse an unambiguous syntax for ES2015 modules

I would like to ask this again, in more depth than on 
twitter ...

The ES6 module support proposal of Node-eps currently 
states:

Note: While the ES2015 specification does not 
forbid
 this extension, Node wants to avoid acting as a rogue agent.
Node has a TC39 representative, @bmeck, to champion 
this proposal.
A specification change or at least an official endorsement of this Node 
proposal would be welcomed.
If a resolution is not possible, this proposal will fallback to the previous 
.mjs file extension 
proposal.

Unambiguous ES6 module support is 
imho:

... an embarrassingly simple solution that would fix a major problem by 
creating a little effort for a minority of users and makes everyone's life 
better.

... so: What is the problem for the TC39 to doing the endorse this effort?

best regards
Martin Heidegger

P.S.: I have noted in a write-up of the ES6 module for Node.js integration that 
this would be important 
http://es2015-node.js.org/#changing-the-es2015-specification
P.P.S.: Thanks to Matthew 
Phillips for pointing 
me to es-discuss.



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

RE: Reflect.hasOwn

[Domenic Denicola]

Reflect is a namespace that contains the proxy traps (it’s a bit of an 
unfortunate name), so we shouldn’t be adding things to it that are not part of 
the meta-object protocol.

A new namespace, or using Object, might be OK. I think that it will still be 
controversial, since this proposal is in support of an objects-as-maps 
programming style which has caused many problems in the past and should not be 
encouraged. See e.g. http://www.2ality.com/2012/11/proto-breaks-webapps.html.

If you are using objects-as-maps safely, you’d use Object.create(null), in 
which case the `in` operator works fine and there's no need for hasOwnProperty 
incantations.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Why ES6 introduced classes yet `Symbol` not to be used with `new`?

[Domenic Denicola]

I believe, but am not sure, that we also decided we would follow that pattern 
for any future primitive types, since in general constructing wrapper objects 
is a bad idea. (I want to say that wrapper objects themselves are a bad idea, 
but I think the conclusion was more subtle than that... they are an important 
part of the semantics, it's just unfortunate that they're so easy to create.)

If some enterprising person wants to dig through the meeting notes, there might 
be some hints there...

> From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] 
>
> Because, to be consistent with Number/String/Boolean you would expect `new 
> Symbol()` to create a  Symbol wrapper object.  But we anticipated that if 
> `new Symbol` was allowed many devs (who lacked an understanding of the 
> difference between primitive values and wrapper objects for primitive values) 
> would code `new Symbol()` with the  expectation that they were creating a 
> Symbol value. This would be a silent bug so we disallowed `new Symbol()`.

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

RE: Why ES6 introduced classes yet `Symbol` not to be used with `new`?

[Domenic Denicola]

Symbol is not a class.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of /#!/JoePea
Sent: Sunday, August 14, 2016 18:31
To: es-discuss 
Subject: Why ES6 introduced classes yet `Symbol` not to be used with `new`?

It seems like `new Symbol()` would be inline with the introduction of classes. 
Why was it chosen not to be constructible? Seems like it would make sense to 
throw an error on `Symbol()` but not `new Symbol()`. Was it to save three 
characters of typing?

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

RE: Function constants for Identity and No-op

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. 
Miller

> What's the issue with document.createElement('object')?

It's a callable exotic object.

>> On Wed, Aug 10, 2016 at 7:20 AM, Michał Wadas  
>> wrote:
>> Function.isFunction? :D

typeof is what you are looking for.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: extending an ES6 class using ES5 syntax?

[Domenic Denicola]

I believe this will work in most cases:

```js
function B() {
  const obj = new A();
  Object.setPrototypeOf(obj, new.target.prototype); // or B.prototype, but if 
you derive from B you'll have to do this dance again

  // use obj instead of this

  return obj;
}
```

Also, in general you should do

```js
Object.setPrototypeOf(B.prototype, A.prototype);
Object.setPrototypeOf(B, A);
```

instead of

```js
B.prototype = Object.create(A.prototype);
```

for slightly better semantics, including class-side inheritance and not 
clobbering `.constructor`.

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

RE: Re: Tracking proposals should be standardized with issues

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of G. Kay Lee

> Unfortunately, the latest stage 0 proposal (Object enumerables), which is an 
> outside contribution (in [the 
> list](https://github.com/tc39/ecma262/blob/master/stage0.md) the column 
> header says "champion" while some people listed are not TC39 members; I 
> believe it was trying to say "proposers"), doesn't really seem to follow this 
> process;

This is incorrect. Leo Balter is employed by Bocoup, a TC39 member. John-David 
Dalton is employed by Microsoft, another TC39 member. Both are champions, not 
"proposers".

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

RE: Subject=Re: Re: Better way to maintain this reference on event listener functions

[Domenic Denicola]

To give some clarity to "whose concern is it", the idea of it being an ES 
concern is that this is a concern for all APIs that accept a callback. 
addEventListener is a simple example.

I think ES has already given an answer to this question: 
`Function.prototype.bind`. I'm not sure what the OP was hoping to accomplish 
that could not already be accomplished with bind. Any possible mechanism (e.g. 
syntactic sugar for a (thisArg, function) pair) would essentially duplicate 
what bind does under the hood.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Async iteration

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Isiah 
Meadows

> By the way, I think observables are getting more headway than async 
> generators. 

This is very inaccurate. They have gotten more conference talks, but not more 
committee headway.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Re: Provide hooks for Content Security Policy (CSP)?

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Ron Waldon

> Are there CSP benefits for other JavaScript environments (e.g. Node.js)?

Yes; it is something that could in theory be exposed through Node's vm module 
(i.e. Realm creation API), which would help certain sandboxing use cases people 
use that for.

> Would there be benefits in applying CSP at the module level? e.g. module A 
> has been vetted and can do these things, whilst module B is less trusted and 
> has strict limitations

I think this is a different proposal than CSP, which operates on a Realm level.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Provide hooks for Content Security Policy (CSP)?

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andrea 
Giammarchi

> Can anyone explain with few words what does this change actual mean for JS ?

It means that JS will now specify how it has been implemented already in every 
browser, in a more rigorous way that allows the CSP spec to move away from [its 
current very imprecise blockage][1] to something more precise. The current 
imprecise blockage is implemented in various different ways in different 
browsers:

- Different errors are thrown (so far I have seen EvalError and TypeError)
- The realm used to determine blocking differs between caller and callee 
realms. That is, given a CSPed window with a non-CSPed iframe, 
otherWindow.eval("foo"), is sometimes blocked and sometimes not. This will 
allow us to specify that it is always blocked (by taking into account both the 
caller and callee realms).

See https://github.com/tc39/ecma262/pull/451 for the exact spec impact.

[1]: https://w3c.github.io/webappsec-csp/#directive-script-src
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Weak Reference proposal

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. 
Miller

> On Tue, Feb 16, 2016 at 7:04 PM, Isiah Meadows 
>  wrote:
>>
>> I know this is only tangentially related, but I just remembered weak refs 
>> are required for a fully conforming DOM implementation because of their GC 
>> semantics. I feel this is relevant with the semi-recent DOM-in-JS efforts. 
>
> What are the GC semantics specified for DOM? How are these observable?

Adding Sebastian and Joris, my co-collaborators on [the jsdom project][1], 
which has at times found the lack of weakrefs in JavaScript troubling. I'm not 
sure if any of the cases we've run into are required, per se, so this might not 
answer your question directly. But answering the related question of "how would 
weakrefs be useful when implementing a self-hosted DOM", I know of at least one 
instance Joris ran into so far. From [the DOM spec][2]:

> For each NodeIterator object iterator whose root’s node document is node’s 
> node document, run the NodeIterator pre-removing steps given node and 
> iterator.

Rephrased: every time you remove a Node from a document, you must go through 
all of the document's NodeIterators and run some cleanup steps (which have the 
effect of changing observable properties and behavior of the NodeIterator).

The weak references come in with the phrase "the document's NodeIterators". The 
only way to implement this that comes to mind is for the document to keep weak 
references to all of the relevant NodeIterators (or, equivalently, to keep an 
*iterable* weak set of them). You don't want the document to hold a strong 
reference, since otherwise the NodeIterators will be kept alive as long as the 
document is, even if they are unreachable from author code. And if they are 
unreachable from author code, they don't matter, since the cleanup steps don't 
have any side effects outside of the NodeIterator itself. 

[How Joris worked around this in jsdom][3] was to have a user-configurable 
option "maxNodeIterators" per jsdom-Document, which gives the maximum number of 
well-behaved NodeIterators the user is allowed to use (default 10). The 
Document holds strong references to these. If the user users more than 
maxNodeIterators NodeIterators, the strong references to the oldest 
NodeIterators are dropped, and all of their public APIs which can change due to 
the aforementioned cleanup steps start throwing errors (instead of giving 
potentially incorrect results). This caps the memory usage at maxNodeIterators 
strong references, in the hope that older ones will not be relevant to the user 
code (e.g. because they would have otherwise been GCed, if not for the strong 
reference).

Obviously this is all pretty silly and weak references would make things a lot 
easier.

---

Other places to look:

- https://dom.spec.whatwg.org/#garbage-collection
- https://xhr.spec.whatwg.org/#garbage-collection (last sentence)
- https://fetch.spec.whatwg.org/#garbage-collection
- https://html.spec.whatwg.org/#garbage-collection-2 (notable by the 
circumstances where there is *not* a strong reference, as well as the last 
clause)


[1]: https://github.com/tmpvar/jsdom
[2]: https://dom.spec.whatwg.org/#concept-node-remove
[3]: 
https://github.com/tmpvar/jsdom/blob/master/lib/jsdom/living/node-iterator.js

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

RE: A promise that resolves after a delay.

[Domenic Denicola]

I think this is a reasonable API, but ES is not the spec for it. ES does not 
have a proper concept of an event loop, and definitely not a proper concept of 
time. Note that setTimeout is not defined in ES, but instead in HTML: 
https://html.spec.whatwg.org/#dom-windowtimers-settimeout

It might be worth proposing this at https://github.com/whatwg/html/issues; the 
form would probably be a new global function.

However, the biggest problem with such proposals is that they lack a way to 
clear the timeout. That is waiting for cancelable promises to arrive, which I 
am working on but I anticipate being contentious due to many differing opinions 
on the best way to do them.

So my best guess is that if you did propose this to HTML people would shout it 
down on the basis of not being able to cancel the timeout, and you'd have to 
wait until we figure out cancelable promises. But it's probably worth trying 
anyway.

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

RE: File Type for Module Goal

[Domenic Denicola]

If you would like to register a MIME type with somebody, anybody at all, then 
https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority is probably 
the right place to do so. They don’t really deal with file extensions, besides 
saying that registrations should include a few commonly used example extensions 
from one or more platforms, alongside “Macintosh File Type Code(s)”. The 
“commonly used” implies to me that you had better start using the proposed file 
extension, commonly, before proposing it for standardization. But who knows.

In practice though, registration with IANA accomplishes nothing, besides making 
people feel better about having gone through the proper channels. What matters 
is how software uses those registrations. For example, text/jscript and 
text/livescript are both accepted by web browsers as denoting JavaScript, but 
are not registered with IANA. If making people feel better is the goal here 
though, to alleviate “expressed concern,” by all means go through the IANA 
registration process.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Bradley 
Meck
Sent: Monday, January 25, 2016 23:08
To: es-discuss 
Subject: File Type for Module Goal

Unclear on the right place to ask for this, and I am now ending up on 
es-discuss.

Node's support for ES modules would ideally be non-ambiguous and not require 
parsing to determine the goal of a file ( 
https://github.com/bmeck/node-eps/blob/es6-module/002-es6-modules.md#determining-if-source-is-an-es6-module
 ). So far we have been met with RTFM it feels like. We were looking at getting 
a file extension added to Node for such things, some of the contributors have 
expressed concern about using an unregistered file type.

I am wondering if this is the right place to find the person to get a `+module` 
suffix added to `application/javascript` so we can officially register a `.jsm` 
or `.es` file type.

Places we have been to so far (with confusing directions on where to go from 
there):

* TC39
* WHATWG

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

RE: File Type for Module Goal

[Domenic Denicola]

Further underscoring how irrelevant IANA registrations appear to be, it seems 
IANA currently associates .js with the following “specification”: 
http://web.archive.org/*/http://devedge.netscape.com/library/manuals/2000/javascript/1.5/reference/<http://web.archive.org/*/http:/devedge.netscape.com/library/manuals/2000/javascript/1.5/reference/>


From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic 
Denicola
Sent: Monday, January 25, 2016 23:22
To: Bradley Meck <bradley.m...@gmail.com>; es-discuss <es-discuss@mozilla.org>
Subject: RE: File Type for Module Goal

If you would like to register a MIME type with somebody, anybody at all, then 
https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority is probably 
the right place to do so. They don’t really deal with file extensions, besides 
saying that registrations should include a few commonly used example extensions 
from one or more platforms, alongside “Macintosh File Type Code(s)”. The 
“commonly used” implies to me that you had better start using the proposed file 
extension, commonly, before proposing it for standardization. But who knows.

In practice though, registration with IANA accomplishes nothing, besides making 
people feel better about having gone through the proper channels. What matters 
is how software uses those registrations. For example, text/jscript and 
text/livescript are both accepted by web browsers as denoting JavaScript, but 
are not registered with IANA. If making people feel better is the goal here 
though, to alleviate “expressed concern,” by all means go through the IANA 
registration process.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Bradley 
Meck
Sent: Monday, January 25, 2016 23:08
To: es-discuss <es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>>
Subject: File Type for Module Goal

Unclear on the right place to ask for this, and I am now ending up on 
es-discuss.

Node's support for ES modules would ideally be non-ambiguous and not require 
parsing to determine the goal of a file ( 
https://github.com/bmeck/node-eps/blob/es6-module/002-es6-modules.md#determining-if-source-is-an-es6-module
 ). So far we have been met with RTFM it feels like. We were looking at getting 
a file extension added to Node for such things, some of the contributors have 
expressed concern about using an unregistered file type.

I am wondering if this is the right place to find the person to get a `+module` 
suffix added to `application/javascript` so we can officially register a `.jsm` 
or `.es` file type.

Places we have been to so far (with confusing directions on where to go from 
there):

* TC39
* WHATWG

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

RE: Object.getOwnPropertyDescriptors still at stage 0

[Domenic Denicola]

I’ve opened a number of minor, mostly-editorial issues on the proposal.

In general, how much more work you need to do depends on how many stages you 
and your TC39 champion (who is it, by the way?) plan to advance the proposal at 
the next meeting. Looking through https://tc39.github.io/process-document/ I’d 
say:


· For stage 1:

o   You need to identify your TC39 champion (it should probably be in the 
document header)

o   You need to identify potential cross-cutting concerns. For example, one 
might be “should there be a Reflect.getOwnPropertyDescriptors”? (to which my 
answer is no, but it should be included.)

· For stage 2:

o   Fix the editorial bugs in the spec text.

· For stage 3:

o   Identify designated reviewers and have them sign off.

o   Get Brian to sign off.

· For stage 4:

o   Write full tests, covering symbols, data descriptors of every variation, 
accessors of every variation (get, get/set, set), throwing getters, and proxies 
with throwing and inconsistent getOwnProperty and ownPropertyKeys traps. (The 
proxies cases might not be necessary.)

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andrea 
Giammarchi
Sent: Wednesday, January 20, 2016 14:50
To: Mathias Bynens 
Cc: es-discuss@mozilla.org
Subject: Re: Object.getOwnPropertyDescriptors still at stage 0

Dear all,
  the current proposal is here 
https://github.com/WebReflection/Object.getOwnPropertyDescriptors#objectgetownpropertydescriptors-proposal

It has been mostly copied, as suggested, from 
https://github.com/tc39/Array.prototype.includes

It has a reference implemntation: 
https://github.com/WebReflection/Object.getOwnPropertyDescriptors/blob/master/reference-implementation/index.js#L12-L68

It has at least one test: 
https://github.com/WebReflection/Object.getOwnPropertyDescriptors/blob/master/test/built-ins/Object/getOwnPropertyDescriptors/has-accessors.js

I wonder if there is a specific amount of tests I should cover, right now I 
just cover the fact it works and it does not ignore accessors.

Woudl a test for symbols and one for data descriptors be enough to move forward?

Thanks.

On Mon, Jan 18, 2016 at 9:12 PM, Mathias Bynens 
> wrote:
On Mon, Jan 18, 2016 at 8:27 PM, Andrea Giammarchi
> wrote:
> Do you (or anyone else) know if that should be filed as a PR to tc39/ecma262
> or if it should just be a repository eventually posted in here?

It should be a repository that can eventually move to the tc39
organization if all goes well. Good luck!

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

RE: Promises as Cancelation Tokens

[Domenic Denicola]

In general I agree that there is a nice conceptual symmetry, but IMO the 
day-to-day impedance mismatch would be simply too great. Compare:

```js
async function f(cancelationToken) {
  cancelationToken.then(() => console.log("FYI you have been canceled"));

  await cheapOperation(cancelationToken);
  if (cancelationToken.state === "fulfilled") {
throw new CanceledOperationError();
  }
  await expensiveOperation(cancelationToken);
}

const token = new Promise(resolve => {
  cancelButton.onclick = resolve;
});

f(token);
```

to the same thing with different names:

```js
async function f(cancelationToken) {
  cancelationToken.whenCanceled(() => console.log("FYI you have been 
canceled"));

  await cheapOperation(cancelationToken);
  if (cancelationToken.canceled) {
throw new CanceledOperationError();
  }
  await expensiveOperation(cancelationToken);
}

const token = new CancelationToken(cancel => {
  cancelButton.onclick = cancel;
});

f(token);
```

I am also unsure when .whenCanceled is necessary (maybe for interfacing with 
cancelable systems that are not cancelation token aware, like XHR?). And it 
seems likely that the rejection path is not necessary.

So, if cancelation tokens are the right path, I'd prefer not reusing promises 
for them. Maybe it argues for easily being able to create a cancelation token 
from a promise, though.

Semi-related: I was recently reading 
http://joeduffyblog.com/2015/11/19/asynchronous-everything/, which has a 
section on Cancelation.

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

RE: Promises as Cancelation Tokens

[Domenic Denicola]

From: Kevin Smith [mailto:zenpars...@gmail.com] 

> And what's the deal, is it canceled or cancelled?  : )

This is kind of the worst. Previous discussion at 
https://github.com/promises-aplus/cancellation-spec/issues/4.

Data seems to favor cancelled:

- 
https://books.google.com/ngrams/graph?content=canceled%2Ccancelled_start=1800_end=2020=15=3=_url=t1%3B%2Ccanceled%3B%2Cc0%3B.t1%3B%2Ccancelled%3B%2Cc0
- http://www.google.com/trends/explore#q=cancelled%2C%20canceled=q
- http://www.googlefight.com/canceled-vs-cancelled.php

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

RE: Confusion with Object.prototype.toString and primitive string datatype

[Domenic Denicola]

This mailing list is largely meant for the further development of JavaScript as 
a language (new feature design, spec review, etc.), and not for questions on 
how JavaScript works. StackOverflow is indeed a better venue for such questions.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Arup 
Rakshit
Sent: Friday, January 1, 2016 12:28
To: Bob Myers ; es-discuss@mozilla.org
Subject: Re: Confusion with Object.prototype.toString and primitive string 
datatype

Hi Bob,

Don’t we have any mailing list to ask JavaScript questions? I like mailing list 
rather than StackOverflow.com :(



On Jan 1, 2016, at 10:56 PM, Bob Myers > 
wrote:

Seems like a good Stack Overflow question, take it there.

On Fri, Jan 1, 2016 at 10:54 PM, Arup Rakshit 
> wrote:
Hi,

Consider the below simple code :

'k' instanceof String; // false
new String('k') instanceof String; // true

Now, When I am inspecting them as below why in both cases the output comes as 
[object String] ?

The below is understood as per the result of the `instanceof` operator.

Object.prototype.toString.call( new String('k') );  // "[object String]”

My confusion comes when I see the below code output :

Object.prototype.toString.call( 'k' );  // "[object String]”

Can anyone please explain it ?
___
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: Re: Backward running version look-behinds

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Yang Guo

> - We have a spec draft: http://claudepache.github.io/ecma262/#sec-pattern, 
> http://claudepache.github.io/ecma262/#sec-pattern
> - We have champions: Gorkem Yakin, Nozomu Katō and Brian Terlson

Hmm, but none of the champions are writing the spec? Probably just want to add 
Claude to the champion list.

> Can we move this to stage 2?

I agree this looks stage 2 worthy. However, the committee has so far exhibited 
the unfortunate dysfunction of being unable to move things between stages 
except during face to face meetings.

At this point I would personally suggest the following. Unofficially, consider 
this to be stage 2; your obligations seem met, even if the committee hasn't had 
time to convene in meatspeace and bless your work. Now, start looking at what's 
required for stage 3: being sure the spec text is complete; finding designated 
reviewers and getting them to sign off; and getting Brian, the editor, to sign 
off on the spec text. If you can get those additional things together in time 
for the January meeting, you should be able to use that meeting to jump from 
stage 1 to stage 3.

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

Re: resolve()/reject() on Promise subclasses and @@species

[Domenic Denicola]

All uses of @@species are to be removed from Promise.race and Promise.all. The 
committee achieved consensus on this, without you.



From: es-discuss  on behalf of C. Scott Ananian 

Sent: Wednesday, November 18, 2015 18:15
To: Boris Zbarsky
Cc: es-discuss@mozilla.org list
Subject: Re: resolve()/reject() on Promise subclasses and @@species


Unfortunately, it's not just a specification device, it has a real effect on 
the behavior of Promise subclasses.  In the case of TimeoutPromise, for 
instance, it affects whether the timeouts apply to *each promise in the array* 
or just to the final result Promise.

I'm hearing through the grapevine (https://github.com/tc39/ecma262/issues/151) 
that it has been decided to change the behavior of Promise.all/race. Have you 
decided to adopt the spec language I proposed above?  There has been precious 
little actual discussion of it, certainly not enough for me to claim any sort 
of consensus has been reached (except perhaps by default, since no one has  
advocated for alternatives).

[https://avatars3.githubusercontent.com/u/3309637?v=3=400]

Remove @@species lookup from Promise.all() and Promise ...
Remove @@species lookup from Promise.all() and Promise.race() #151
Read more...



  --scott

On 11/4/15 11:22 PM, C. Scott Ananian wrote:
see my previous message for the exact wording proposal which
changes step 6.

https://esdiscuss.org/topic/performpromiseall#content-6 you mean?

I don't have a strong opinion on it, honestly.  The existence of the 
intermediate promises in all/race seems mostly to be a specification device to 
make it easier to deal with people passing in not-thenable-at-all values, from 
my point of view, so I'm not sure I have a principled opinion on how they 
should be constructed.

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

Re: resolve()/reject() on Promise subclasses and @@species

[Domenic Denicola]

I still think everything should go through @@species. I don't understand the 
utility of @@species if it is not uniformly applied to constructing new 
instances (in both instance and static methods). But it seems that ES15 decided 
to only use @@species for instance methods so I guess that's where we're stuck.



From: "C. Scott Ananian" 
Sent: Nov 5, 2015 3:20 AM
To: Allen Wirfs-Brock
Cc: es-discuss
Subject: Re: resolve()/reject() on Promise subclasses and @@species


As referenced in the cited thread
(https://esdiscuss.org/topic/performpromiseall#content-6) there are
actually two uses of the Promise constructor in the definition of
`all` and `race`.  To quote myself:

> [N]ote that the implementations given for `Promise.all` and `Promise.race` 
> use Promises in two different ways: (1) every element of the array argument 
> has `C1.resolve(elem).then()` applied to it, and (2) the result is 
> constructed with `NewPromiseCapability(C2)`.  It's not entirely clear to me 
> that C1 and C2 should be the same.  Consider the `TimeoutPromise`: do we want 
> to apply a timeout to every element individually *and* to the result as a 
> whole?
>
> It seems that C1 might use species (to avoid the timeout/weak reference), but 
> C2 ignore it (to apply the timeout/weak reference to the final result)
>
>[...] [I]f we decided that `WeakPromise.all()` should return a `WeakPromise` 
>then I'd suggest that we change step 6 from:
>> Let promiseCapability be NewPromiseCapability(C).
>to
>> Let promiseCapability be NewPromiseCapability(this).
>in both `Promise.all` and `Promise.race`, but leave the definition of C 
>otherwise alone, so that internally-created promises honor the species.

The subtly of this detail of the spec was (for me at least) one of the
reasons I didn't push for a change to `Promise.all` and `Promise.race`
at the time.  And, as I wrote then, the current semantics do have a
plausible consistency, given future `Promise.prototype.all` and
`Promise.prototype.race` methods.

I'm certainly willing to reopen this for discussion, but I'd like to
see some hard thought given to the two separate uses in the
definition.
  --scott

On Fri, Oct 30, 2015 at 5:21 PM, Allen Wirfs-Brock
 wrote:
> +1
>
> Allen
>
> On Oct 30, 2015, at 10:19 AM, Claude Pache  wrote:
>
>
> Le 29 oct. 2015 à 03:51, Boris Zbarsky  a écrit :
>
> I was just implementing subclassing of Promise in Gecko, when I realized
> that given a Promise subclass MyPromise these two calls:
>
>  MyPromise.race([])
>  MyPromise.all([])
>
> will take MyPromise[@@species] into account when creating the return value,
> but these two calls:
>
>  MyPromise.resolve()
>  MyPromise.reject()
>
> will not; they will invoke MyPromise itself, not MyPromise[@@species].
>
> This is because
> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.all and
> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.race do the
> whole @@species thing but
> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.reject and
> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve do not.
>
> Is this behavior intentional?  If so, I'd really like to understand the
> reason for it.
>
> -Boris
>
>
> Relevant discussion: https://esdiscuss.org/topic/performpromiseall
>
> As I understand, the specified behaviour is an accident of history.
> Previously, `Promise.resolve()` and `Promise.reject()` used the species
> pattern in order to determine the constructor to be used, just as
> `Promise.all()` and `Promise.race()`. Then, at the last minute, it was
> decided that it wasn’t the best semantics for `Promise.resolve()`, and it
> was corrected. For `Promise.all()` and `Promise.race()`, the motivation
> wasn’t stronger than the lack of time.
>
> Should it be corrected before @@species is widely implemented? I think so.
> The arguments I give are:
>
> * Overall consistency in the language. Except for the two offending Promise
> static methods, all uses of `@@species` in the ES2015 spec (15 uses) are for
> the following pattern: Starting from one instance, one constructs a derived
> object for that instance. (The effective lookup of the @@species property is
> factored in the SpiecesConstructor and ArraySpeciesCreate abstract
> operations.)
>
> * Also, in static methods like `Promise.all` and `Promise.race`, a
> constructor is explicitly provided by the user: simply use it. Compare with
> what is done for arrays:
>
> Array.from(someArray) // use the Array constructor explicitly provided.
> Array.of(x, y, z) // ditto
>
> someArray.slice(0) // compute the constructor to be used through some
> algorithm involving @@species.
> [].concat(x, y, z) // ditto
>
> —Claude
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss 

RE: Any reason template string with empty interpolation placeholder (`${}`) throws?

[Domenic Denicola]

If there were to be a value for `${}`, `undefined` makes more sense to me than 
the empty string as a default “nothing” value.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Caitlin 
Potter
Sent: Thursday, October 22, 2015 19:20
To: Mark S. Miller 
Cc: es-discuss@mozilla.org
Subject: Re: Any reason template string with empty interpolation placeholder 
(`${}`) throws?

Cute, but nobody is realistically going to do that.

Possible valid uses for the empty placeholder:

- Contents of expression commented out, maybe debugging if it causes side 
effects which may be harmful
- Expression is a placeholder, with contents soon to come (mentioned by OP)

The DSL thing is a non-issue, because the empty expression didn't need to be 
included in the list of expressions, and if it is included, DSLs can be smart 
enough to deal with it, and should probably be implemented as a recursive 
descent parser on top of the interpolated text anyways

Ease of use, ease of debugging, ease of editing. Users of JS don't make the 
distinction between a Statement and Expression or ExpressionStatement, and 
interpolated strings are very much about strings.

On Oct 22, 2015, at 7:05 PM, Mark S. Miller 
> wrote:
It is an unnecessary special case. The empty string is a valid statement (aside 
from the semicolon) but not a valid expression. The syntax of what appears 
between the curlies is expression.

Having it default to the empty string makes no sense. Why not 0, false, null, 
or undefined? Remember that template strings can be used to make arbitrary 
objects using any DSL that your tag knows how to parse. There's nothing about 
template strings that is about strings in either the substitution values or the 
result values.

If you want the equivalent of `${''}`, just say `${''}`.



On Thu, Oct 22, 2015 at 6:31 PM, Caitlin Potter 
> wrote:

Doesn't necessarily seem like a bad idea. I could be on board with that.

> On Oct 22, 2015, at 6:18 PM, Mohsen Azimi 
> > wrote:
>
> Pardon my lack of use of proper terminology.
>
> This is kind of annoying working with large template strings. When I leave an 
> interpolation placeholder(what's the right name?) empty it blows up all my 
> code.
>
> Can it be forgiving like Ruby and CoffeScript and just replace it with empty 
> string?
> ___
> 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



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

RE: The name of Array.prototype.includes

[Domenic Denicola]

https://github.com/tc39/Array.prototype.includes#why-includes-instead-of-has

> -Original Message-
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Axel
> Rauschmayer
> Sent: Tuesday, October 13, 2015 16:33
> To: es-discuss mailing list 
> Subject: The name of Array.prototype.includes
> 
> There are two existing methods that are loosely similar to
> `Array.prototype.includes()`:
> 
> 1. `String.prototype.includes()`
> 2. `Set.prototype.has()`
> 
> Isn’t #2 more similar than #1? Shouldn’t the method be called
> `Array.prototype.has`, then?
> 
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
> 
> 
> 
> ___
> 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: Exponentiation operator precedence

[Domenic Denicola]

I object to #4. Disallowing perfectly reasonable math expressions (Claude's is 
a good example) makes this operator too surprising to include in the language.



From: Brendan Eich 
Sent: Sep 24, 2015 13:18
To: Mark S. Miller; Claude Pache
Cc: es-discuss
Subject: Re: Exponentiation operator precedence

Right. It's confusing because (as opposed to Math), ** is not a superscripting 
operator whose typography suggests higher precedence than -, and this matters 
for the sign of the result when exponentiating.

Claude, the Math folks won't often need to negate the result, but when they do, 
they'll have to parenthesize. That's the price of the typographic shift and the 
precedence inversion that it suggests to many people.

/be

On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller 
> wrote:


On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache 
> wrote:

Le 24 sept. 2015 à 16:11, Brendan Eich 
> a écrit :

And indeed apart from dot (a special form whose right operand must be a lexical 
identifier-name) and square brackets (which isn't an infix operator per se), 
unary operators bind tighter than binary in JS as in C and other C-derived 
languages.

I just wonder why it is important that unary binds tighter? For instance, 
before I carefully studied the issue of this thread, I have never expected that 
unary minus binds tighter than binary


Before Jason pointed out the discrepancy:
  * all of us on the committee who were engaged with the proposal
  * including myself,
  * all those who reviewed the proposal,
  * and all those who implemented the proposal
had the opposite naive expectation. That's the point. In the absence of 
learning about this case specifically, many people will be unpleasantly 
surprised by #2, and many by #3. Therefore #4 wins. (Actually, it just won ;).)




multiplication operator in expressions like `-2*x` (although it does not matter 
in that case).


without having to parenthesize unduly, but one cannot write

let z = -x ** y;

The user is forced by an early error to write either (-x)**y or -(x**y).

In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ with 
mandatory parentheses, so I don’t expect that many people will be tempted to 
miswrite it `-x ** n`.

Making the parentheses mandatory here will be somewhat annoying in perfectly 
reasonable expressions, where you usually don’t use parentheses in real math 
notation., like:
```
let s2 =  - x**2 - y**2 - z**2 +  t**2
```

—Claude





--
Cheers,
--MarkM

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

RE: System.import()?

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of James 
Burke


 In the spirit of the extensible web, defining these lower level APIs and more
 of the loader would make it possible to use custom elements to help
 prototype a module tag. The custom element mechanism can be used in a
 similar way to how JS transpilers are used for the existing module syntax.

No, custom elements cannot prototype the module tag, because custom elements 
will always be parsed as unknown elements. So e.g.

```html
custom-module
const stuff = pStuff/p;
/custom-module
```

will be parsed as

```
custom-module
|- text node: const stuff = 
|- p
| text node: Stuff
| - text node: ;
```

and of course it gets much worse if you use any elements that do something 
visual or interesting, like `img` or `custom-module` or `script`.

This is why we need to use an existing parsed-as-is element (namely `script`, 
although I guess we could maybe make `style` work in a pinch), and why custom 
elements won't work.

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

RE: System.import()?

[Domenic Denicola]

From: Jason Orendorff [mailto:jason.orendo...@gmail.com]

 HostResolveImportedModule is widely implemented by compilers, though
 not by browsers. People are writing, using, and sharing ES6 modules today.

So what is your proposal then? Just standardize the node module resolution 
algorithm, since that is what transpilers are doing?

 It is working, and the people using it have a need for the dynamic API to go
 along with the static syntax, for reasons I pointed out in the initial post.

It is not working outside of transpilers, which implement nonstandard 
resolution algorithms. The same transpilers implement JSX, but I don't think 
we'd take that as a reason to say that JSX is working and now let's start 
discussing how to standardize a reflective JSX layer.

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

RE: System.import()?

[Domenic Denicola]

From: Jason Orendorff [mailto:jason.orendo...@gmail.com]


 Here's what I had in mind:

I have re-read this a few times and still don't understand how you expect this 
to be implemented in a standards-compliant way given that 
HostResolveImportedModule is not standardized. It doesn't seem to change the 
equilibrium at all.

If this is just to help transpilers, well, they can already do whatever they 
want, with no guarantees of future compatibility, like they are doing now. They 
already invented nonstandard semantics for HostResolveImportedModule; they 
might as well add a nonstandard property like `System` to the global and give 
it a nonstandard method named `import` with nonstandard behavior.

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

RE: Please help with writing spec for async JSON APIs

[Domenic Denicola]

My understanding of most streaming JSON use in Node.js is that it actually is 
newline-delimited JSON. That is, each line is parsed, delivered, and 
processed as a single chunk containing a JSON value, and the streaming nature 
comes from the incremental processing and backpressure as applied in between 
newline-delimited chunks.

Part of the advantage of this is that it's extremely easy to specify and 
implement how it works.

Bruno seems to indicate he's run in to use cases where it'd be useful to 
process a normal JSON object in a streaming fashion. That seems like a harder 
problem, indeed necessitating a SAX-like API.

 -Original Message-
 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
 Brendan Eich
 Sent: Sunday, August 2, 2015 21:26
 To: Bruno Jouhier
 Cc: es-discuss
 Subject: Re: Please help with writing spec for async JSON APIs
 
 Exactly! Incremental and async, i.e., streaming.
 
 XML quickly needed such APIs
 (https://en.wikipedia.org/wiki/Simple_API_for_XML,
 https://en.wikipedia.org/wiki/StAX). JSON's in the same boat.
 
 /be
 
 Bruno Jouhier wrote:
  A common use case is large JSON feeds: header + lots of entries +
  trailer
 
  When processing such feeds, you should not bring the whole JSON in
  memory all at once. Instead you should process the feed incrementally.
 
  So, IMO, an alternate API should not be just asynchronous, it should
  also be incremental.
 
  FWIW, I have implemented an incremental/evented parser for V8 with a
  simple API. This parser is incremental but not async (because V8
  imposes that materialization happen in the main JS thread). But, if
  the V8 restriction could be lifted, it could be made async with the
  same API. See https://github.com/bjouhier/i-json
 
  i-json's API is a simple low level API. A more sophisticated solution
  would be a duplex stream.
 
  There was also a long discussion on this topic on node's GitHub:
  https://github.com/joyent/node/issues/7543
 
  Bruno
  ___
  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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Extensible destructuring proposal

[Domenic Denicola]

From: Samuel Hapák [mailto:samuel.ha...@vacuumapps.com] 

 Could you please explain it on example?

 Let’s say I have
 
 ```
 let book = Map{author: {name: “John”, surname: “Doe”}, birthdate: 
 “10-10-1990”};
 ```

 How would you extract `birthdate`? How would you extract `name`?

Your syntax here is invalid in at least four different ways. Let's assume you 
wrote something with valid syntax, like

```js
let book = new Map([[author, { name: John, surname: Doe }], [birthdate, 
10-10-1990]]);
```

Then:

```js
const [[, { name }], [, birthdate]] = book.entries();
```

If this is still confusing, you may wish to turn to StackOverflow for 
clarification, instead of es-discuss. You can test such things in Firefox, 
although you need to use `var` instead of `const` or `let`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extensible destructuring proposal

[Domenic Denicola]

Well,  the spec says they are ordered, so I'm not sure where you're getting 
that from.



From: Bergi a.d.be...@web.de
Sent: Jul 21, 2015 8:53 AM
To: Domenic Denicola; es-discuss
Subject: Re: Extensible destructuring proposal


Domenic Denicola schrieb:
 For maps you can just do

 ```js
 const [[k1, v1], [k2, v2], ...rest] = map.entries();
 ```

The problem with this is that you would need to know the order of the
keys in the map. Your code does only extract the first and second
key-value pairs, allowing us to get the key values of them, but this
syntax does not allow us to extract the value for a given key from
somewhere in the map.
Predictability is all fine, but I still consider maps to be inherently
unordered.

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

Re: String.prototype.trimRight/trimLeft

[Domenic Denicola]

They're already shipping with the wrong names in every browser.



From: Norbert Lindenberg ecmascr...@lindenbergsoftware.com
Sent: Jul 20, 2015 23:25
To: Dmitry Soshnikov
Cc: Norbert Lindenberg; Domenic Denicola; es-discuss
Subject: Re: String.prototype.trimRight/trimLeft


These methods should be called trimStart and trimEnd. Determining which parts 
of the string are left and right would require running the Unicode 
Bidirectional Algorithm, and that’s probably not intended here.

Norbert


 On Jul 20, 2015, at 15:09 , Dmitry Soshnikov 
 dmitry.soshni...@gmail.commailto:dmitry.soshni...@gmail.com wrote:

 Will somebody be so kind to present this on the following meeting for me, I 
 don't have an ability to attend, and the change is pretty small (July 28th, 
 2015)?

 People were asking, and we'd like to polyfill it instead of doing regexp 
 replaces. Again the spec is here: 
 https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048

 Thanks!

 Dmitry

 On Wed, Mar 18, 2015 at 2:26 PM, Dmitry Soshnikov 
 dmitry.soshni...@gmail.commailto:dmitry.soshni...@gmail.com wrote:
 OK, the spec is here: 
 https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Will appreciate 
 review and corrections if needed.

 Dmitry

 On Tue, Mar 17, 2015 at 7:36 PM, Dmitry Soshnikov 
 dmitry.soshni...@gmail.commailto:dmitry.soshni...@gmail.com wrote:
 Sounds good. Yeah, I'll spec it, and add the test.

 Dmitry


 On Tuesday, March 17, 2015, Domenic Denicola 
 d...@domenic.memailto:d...@domenic.me wrote:
 Yeah, this seems like a shoe-in for ES7. It will probably be able to advance 
 through the stages very quickly given that it already has three (four?) 
 shipping implementations.



 Someone just needs to write up a formal spec (using Ecmarkdown! ^_^) and 
 test262 tests. The only snag would be if you find non-interoperable behavior 
 between browsers in the course of writing those tests, and need to get some 
 patches accepted before you can reach stage 4.



 From: es-discuss 
 [mailto:es-discuss-boun...@mozilla.orgmailto:es-discuss-boun...@mozilla.org]
  On Behalf Of Dmitry Soshnikov
 Sent: Wednesday, March 18, 2015 05:02
 To: Tab Atkins Jr.
 Cc: es-discuss
 Subject: Re: String.prototype.trimRight/trimLeft



 Right, so from the several feedback I had so far, it seems it will make sense 
 just to add to ES7? In this case we'll be able to polyfill now, the spec'ing 
 it will be trivial (I'll add the spec).



 I guess we just need to confirm it's good to go to ES7?



 Dmitry



 On Tue, Mar 17, 2015 at 12:21 PM, Tab Atkins Jr. 
 jackalm...@gmail.commailto:jackalm...@gmail.com wrote:

 On Mon, Mar 16, 2015 at 11:07 PM, Leon Arnott 
 leonarn...@gmail.commailto:leonarn...@gmail.com wrote:
  I believe opinion hasn't shifted since it was discussed
  [previously](https://esdiscuss.org/topic/standardizing-more-de-facto-functions)
  - in short, show me the cowpath. (But, I've just learned that the IE
  Technical Preview now supports trimLeft/trimRight, so there'll soon be
  support for it in all the major engines. Maybe the cows are there after
  all.)

 I use both lstrip() and rstrip() in Bikeshed (a Python project):

 https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=lstriptype=Code
 https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=rstriptype=Code

 In particular, lstrip() is used when I'm separating a key and value; I
 don't want to mess with the value much at all, just pull off the
 whitespace at the start.  rstrip() is used when I know I don't need to
 strip from the left side, because I'm just pulling off newlines or
 something, so might as well let the program avoid even trying.

 ~TJ





 ___
 es-discuss mailing list
 es-discuss@mozilla.orgmailto: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: Extensible destructuring proposal

[Domenic Denicola]

For maps you can just do

```js
const [[k1, v1], [k2, v2], ...rest] = map.entries();
```

There is no need to add more complexity to object destructuring (which should 
only be used for objects and their string keys).

-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Samuel 
Hapák
Sent: Tuesday, July 21, 2015 08:29
To: es-discuss
Subject: Re: Extensible destructuring proposal


 On 21.7.2015, at 9:34, Andreas Rossberg rossb...@google.com wrote:
 
 People reading code will (rightfully) expect destructuring to be syntactic 
 sugar for property access. I don't think it's worth breaking that 
 equivalence. If you want user-defined patterns then they should be 
 syntactically distinct from existing forms.

This is already not true for array destructuring. You can use it with any 
iterables, not only with arrays.

`@@get` should be implemented only by “Map like” data structures. Destructuring 
is usually used to extract deeply nested data from `Object`. I find hard to 
believe that someone would deliberately use destructuring on `Map` or similar 
structure to extract methods:

```
// very strange use of destructuring, don’t believe anyone is doing that const 
{get, has, set} = myMap // instance of Map() ```

Much more common use case is that you have nested structure of “Map like” 
structures and want to easily retrieve values.

Btw. this change is backward compatible, because it does not change behavior of 
existing code. It just gives you ability to provide users with new 
datastructures.

 
 Also, destructuring patterns are meant to match, and be the logical inverse 
 of, literal syntax. Consequently, from my perspective at least, extensible 
 destructuring would require first introducing extensible literal syntax in a 
 symmetric manner. I think it would be unnecessarily surprising if for random 
 patterns they didn't match up (worse, if you cannot even tell the meaning 
 syntactically, but it depends on whatever object you happen to get).
As I have pointed out, this is not true for iterable destructuring.

```
[a, b, c] = someIterable; // someIterable does not have to be Array ```

This can be similarly surprising:
`someIterable[0] !== a // true`

Thanks,

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

RE: Instance bound class methods

[Domenic Denicola]

I don't think this is possible to do in a memory-efficient way. I thus think it 
should not be easy, nor concise. Doing inefficient things should be painful and 
discouraged.

-Original Message-
From: Sebastian Markbåge [mailto:sebast...@calyptus.eu] 
Sent: Friday, July 17, 2015 19:14
To: Domenic Denicola
Cc: Matthew Robb; es-discuss@mozilla.org  es-discuss
Subject: Re: Instance bound class methods

Domenic, would you care to propose an alternative that is concise and memory 
efficient if it is an anti-pattern?

That would be helpful and constructive (your comment, not so much).


 On Jul 13, 2015, at 8:27 AM, Domenic Denicola d...@domenic.me wrote:
 
 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan 
 Eich
 
 You're counting on the property assignment being moved into the constructor, 
 where `this` is bound. In a class body in ES6 (without property assignment 
 extension), especially in the top level where method defintiions go, `this` 
 isn't obviously bound to the newly constructed instance.
 
 Ok, that's kind of a nit, or an observation. No worries.
 
 Yeah, just to highlight this, the property initializer syntax is very far 
 from reaching consensus, and I wouldn't take that for granted and then ask if 
 we can build something else on top of it.
 
 Bigger question is what we want: method per instance allocation cost, which 
 what you did imposes? Or something that can be more efficiently implemented, 
 such as what Strong/SoundScript proposes (last I looked). 
 The latter is what Java and C++ do. Then the trick is enabling first-class 
 function extraction from method, which is a pay-for-what-you-ask-for 
 alternative to allocation per method per constructed instance.
 
 Agreed. The pattern shown is really an antipattern in my book (and according 
 to conventional JavaScript wisdom). My understanding is that React encourages 
 this antipattern, but that's not something we should encourage at a language 
 level. (Which is part of why property initializer syntax may not make it, at 
 least not in the form you show).
 ___
 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: for statement with index and value

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew 
Robb

 Why not use the new meta syntax?

This is pretty ingenious. If I thought this was a real problem that needed 
solving, I'd definitely go this route. (But, I think that using .entries() and 
destructuring is fine, and there's no need to add new syntax to save people a 
few characters.)

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

RE: for statement with index and value

[Domenic Denicola]

From: Tingan Ho [mailto:tinga...@gmail.com] 

 But they aren't clean solutions to a wildly popular problem.

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

Re: Clarification for derived promises

[Domenic Denicola]

Yes.



On Tue, Jul 14, 2015 at 10:10 AM -0700, Nicholas C. Zakas 
standa...@nczconsulting.commailto:standa...@nczconsulting.com wrote:

Hi all,

I'm trying to wrap my head around derived promises and wanted to ask for
a bit of clarification around how `Promise.resolve()` works from a
derived class. Consider this:

```
class MyPromise extends Promise {}

var p1 = new Promise(function(resolve, reject) {
 resolve(42);
});

var p2 = MyPromise.resolve(p1);
p2.then(function(value) {
 console.log(value);
});
```

Am I correct in believing that:

1. `p1` is resolved upon being passed to `MyPromise.resolve()`? I
believe this is what happens in 25.4.4.5 Step 6
(http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve)
2. `p2` is an instance of `MyPromise` that is resolved with a promise
value of 42.

Thanks!

--
___
Nicholas C. Zakas
http://www.nczonline.net

___
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: Instance bound class methods

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan 
Eich

 You're counting on the property assignment being moved into the constructor, 
 where `this` is bound. In a class body in ES6 (without property assignment 
 extension), especially in the top level where method defintiions go, `this` 
 isn't obviously bound to the newly constructed instance.
 
 Ok, that's kind of a nit, or an observation. No worries.

Yeah, just to highlight this, the property initializer syntax is very far from 
reaching consensus, and I wouldn't take that for granted and then ask if we can 
build something else on top of it.

 Bigger question is what we want: method per instance allocation cost, which 
 what you did imposes? Or something that can be more efficiently implemented, 
 such as what Strong/SoundScript proposes (last I looked). 
 The latter is what Java and C++ do. Then the trick is enabling first-class 
 function extraction from method, which is a pay-for-what-you-ask-for 
 alternative to allocation per method per constructed instance.

Agreed. The pattern shown is really an antipattern in my book (and according to 
conventional JavaScript wisdom). My understanding is that React encourages this 
antipattern, but that's not something we should encourage at a language level. 
(Which is part of why property initializer syntax may not make it, at least not 
in the form you show).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: treated as a module if ...

[Domenic Denicola]

To be explicit: there is no way to look at a string of JavaScript text and tell 
whether it should be treated as a module or a script. In many instances the 
same string can be treated as both. The decision is made by the execution 
environment.

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

RE: Will any new features be tied to constructors?

[Domenic Denicola]

From: Anne van Kesteren [mailto:ann...@annevk.nl] 

 I don't see how this matters given that Dmitry's design depends on not 
 executing JavaScript while constructing the element. Whereas if you put 
 this[Element.init]() in the constructor it totally would.

Dmitry's design does *not* depend on that. In fact Dmitry's design includes 
this[Element.init]() in the constructor. See 
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0230.html

The essence of Dmitry's design is to disallow custom allocation, while allowing 
custom initialization. This allows you to optionally decouple the two stages 
when necessary (upgrades, cloning, etc.) while also getting the goodness where 
author code doing `new MyElement(...)` calls both built-in allocation and 
custom initialization immediately.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Will any new features be tied to constructors?

[Domenic Denicola]

From: Anne van Kesteren [mailto:ann...@annevk.nl] 

 In a world where custom elements are normal subclassed objects, they would 
 just call super() from the constructor to set the browser-supplied bits and 
 then add whatever else is needed themselves.

Yes, that is the Dmitry proposal.

 Or are you saying that super() would fully allocate the object

Yes, that is how ES2015 works.

 and prevent adding new private state

Apparently Kevin and Allen's private state proposal is based on private state 
being installed at allocation time, so yes, since super() fully allocates the 
object, this would prevent private state for custom elements.

Personally I think this is a definite negative for any such private state 
proposal, since it makes it significantly less expressive than weak maps. But I 
suppose when the proposal is proposed, we will have that discussion.

 (or other features tied to constructors)?

Well, it depends on if those features are tied to allocation (like this private 
state proposal) or to initialization.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Will any new features be tied to constructors?

[Domenic Denicola]

From: Anne van Kesteren [mailto:ann...@annevk.nl] 

 Fair, but it does depend on that not always being invoked at the same time as 
 the constructor. So even if not being lexically part of the constructor was 
 fine, you could still not depend on it being invoked at the same time.

Yeah, you're right. But only because this private state feature is for some 
reason tied to object allocation. So going back to your original question,

 To clarify, since this was not completely clear, the question is whether 
 anything other than object allocation will be allowed only through a 
 constructor?

I guess the answer is still no :).

The question is whether this private state feature design (1) really needs to 
be tied to allocation; (2) if it does, then will it even be usable for custom 
elements?

I.e., do you see any plausible world in which you're allowed to create a custom 
element with a custom allocator, instead of the browser-supplied HTMLElement 
one? 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Will any new features be tied to constructors?

[Domenic Denicola]

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] 

 Do one has yet explained to me, what is wrong with simply initially  
 inserting a dummy (generic) custom element node during DOM parsing and latter 
 (after the required JS code has loaded) replacing that node with a new more 
 specific node that is an instance of the named subclass.

Anne explained this to you in 
https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors#content-3.
 There's also the issue that replacing nodes that have children gets much more 
complicated, especially if those nodes are high up in the tree. More detail at 
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md.

 My premise is that once script is running DOM nodes can be arbitrarily 
 added/removed/modified as a side-effect of any script function.

In practice, this is not how one programs against the DOM. One assumes that 
things generally don't change except for good reason (i.e. author-initiated 
reason). It's common practice to save `document.querySelector('#my-thingy')` to 
a variable, and operate on it for many event loop turns, until some known event 
occurs. (Like Ajax fake page navigation, or blowing away the parent component, 
or closing a dialog, similar.)

It's decidedly bad practice to re-query the DOM for an element every time you 
want to use it, which seems to be what you're advocating as necessary.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Will any new features be tied to constructors?

[Domenic Denicola]

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] 

 This is model is, to a first approximation the C++ model and the also the 
 model the ES currently uses for built-ins so I don't expect that UA 
 allocators will have significant difficulties supporting it.

Really?

Right now the UA allocators for all elements contains a single private slot, a 
pointer to the backing C++ object. Then a whole parallel hierarchy, of the C++ 
object tree mapping to multiple corresponding JS object trees, follows from 
this. Private state is, of course, stored in the backing C++ object. Maybe some 
implementers can correct, but I doubt retrofitting this structure to support 
additional arbitrary author-defined private slots, introduced at any level in 
the hierarchy, is at all insignificant.

Similarly, for several V8 built-ins, private state is not done via the 
allocator at all, but instead via private symbols that act quite similar to 
data properties. They can be added or removed at any time. In short, they're 
much more part of initialization than of allocation.

I don't think there's anything like the model the ES spec uses in play in 
implementations. I would anticipate significant difficulties.

 It has lots of very desirable characteristics.  

Forgive me if I am speaking in ignorance. But from what has been presented so 
far, it seems to have one strongly *un*desirable characteristic, which is that 
it is no longer possible to decompose a non-custom-allocator constructor into 
base-class allocator and subclass initialization. That is, previously it was 
easy to emulate the constructor for

```js
class Derived extends Base {
  constructor(...args) {
super(a, b, c);
doInitCode(this, ...args);
  }
}
```

via a function

```js
function makeDerived(...args) {
  const o = Reflect.construct(Base, [a, b, c], Derived);
  doInitCode(o, ...args);
  return o;
}
```

This allows you to recover the allocation/initialization split that was lost 
when moving away from @@create, while still preserving the instantiation reform 
benefits in the general case.

It sounds like this kind of emulation is not possible with your private state 
proposal. Whereas, of course, it is possible with weak maps (which exist today) 
or private symbols (what V8 uses today internally).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Will any new features be tied to constructors?

[Domenic Denicola]

Thanks for the corrections Boris. I was basing what I said on a half-remembered 
version of 
https://ask.mozilla.org/question/850/how-do-webidl-methodsgetterssetters-tell-whether-objects-are-of-the-right-types/,
 but upon re-reading that I see that I missed the at least in at least one 
reserved slot, and made a few other unwarranted assumptions along the way.

My apologies to Allen and everyone else for misleading assertions.

-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boris 
Zbarsky
Sent: Thursday, July 2, 2015 00:35
To: es-discuss@mozilla.org
Subject: Re: Will any new features be tied to constructors?

On 7/1/15 11:12 AM, Domenic Denicola wrote:
 Right now the UA allocators for all elements contains a single private slot, 
 a pointer to the backing C++ object.

Just as a note, this is true conceptually in the specifications but happens to 
not be true as a matter of implementation reality in either Gecko or (planned? 
not sure where they are with their fused allocation
setup) Servo.  There can be various numbers of preallocated private slots in 
practice.

The UA allocators for elements contain some UA-determined set of private slots 
would be a better way of putting it.

 Private state is, of course, stored in the backing C++ object.

This is, again, not true for Gecko.  Some private state is stored in the 
backing C++ object.  Some (e.g. the backing Map for an IDL maplike) is stored 
directly in a private slot of the JS object.  This is a matter of 
implementation convenience, of course; no spec defines where these things 
should be stored; it just happened to be easier to do the GC bits this way.

 Maybe some implementers can correct, but I doubt retrofitting this structure 
 to support additional arbitrary author-defined private slots, introduced at 
 any level in the hierarchy, is at all insignificant.

I can't speak to the difficulties of doing or not doing this in SpiderMonkey 
without us having implemented this.  However, I suspect that whatever setup 
normal Object ends up using here in SpiderMonkey would also be usable by DOM 
objects...

I obviously can't speak for other implementations.

-Boris
___
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: Will any new features be tied to constructors?

[Domenic Denicola]

Allen, Kevin: I think the key question about private state and how it interacts 
with Anne's question is this.

Given a base class looking roughly like

```js
class HTMLElement extends Element {
  constructor(...) {
super(...);
// ...other stuff...
this[Element.init]();
  }
}
```

then, will the following work?

```js
class CustomElement extends HTMLElement {
  [Element.init]() {
// initialize private state
  }
}
```

Or would an actual constructor be required?

```js
class CustomElement extends HTMLElement {
  constructor(...args) {
super(...args);
// initialize private state
  }
}
```

Stated another way, which might be a bit stronger: will it be *lexically* 
required that private state initialization be within the constructor, or will 
it only be *temporally* required?

That question is, I think, what Anne is essentially asking when he asks about 
features that are tied to constructors.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Will any new features be tied to constructors?

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C. Scott 
Ananian

 But the design might work well as a proxy object?  It could delegate to the 
 real object, with its private slots, after that object is created.

We briefly discussed this with the V8 team. Their opinion was that making fast 
proxies was a problem at least as hard as making proto-swizzling work 
seamlessly. Not to mention all the additional complexities introduced by 
private state and proxies, which there are a few centithreads in the archives 
about.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Will any new features be tied to constructors?

[Domenic Denicola]

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] 

 no, not in the way that I believe you intend

Can you explain why? Is the design you and Kevin have been working on based on 
lexical restrictions?

 It isn't that  subclass specific private state initialization must be 
 performed in the constructors. In the design that Kevin and I have been 
 working on,  the total number of private state slots (and some meta data for 
 each one) must be knowable and fixed when an object is allocated   (in other 
 words, private slots cannot be added to an object after it is initially 
 allocated).

This seems like it then compares poorly with weak maps for private state. It 
makes sense as a strong mode restriction, but not as a default one...

Anyway, the design for upgradable custom elements is based around the idea that 
subclasses would never need to customize the allocator, thus allowing the UA to 
do their magical allocation of C++ HTMLElement stuff. If private state requires 
customizing the allocator, I am not sure that custom elements would be able to 
take advantage of it anyway... I suppose it depends on the details of the 
proposal.

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

RE: RegExp.escape()

[Domenic Denicola]

All of these should be building on top of RegExp.escape :P

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. 
Miller
Sent: Saturday, June 13, 2015 02:39
To: C. Scott Ananian
Cc: Benjamin Gruenbaum; es-discuss
Subject: Re: RegExp.escape()

The point of this last variant is that data gets escaped but RegExp objects do 
not -- allowing you to compose RegExps:   re`${re1}|${re2}*|${data}`
But this requires one more adjustment:



   function re(first, ...args) {
 let flags = first;
 function tag(template, ...subs) {
   const parts = [];
   const numSubs = subs.length;
   for (let i = 0; i  numSubs; i++) {
 parts.push(template.raw[i]);
 const subst = subs[i] instanceof RegExp ?

   `(?:${subs[i].source})` :
 subs[i].replace(/[\/\\^$*+?.()|[\]{}]/g, '\\amp;');
 parts.push(subst);
   }
   parts.push(template.raw[numSubs]);
   return RegExp(parts.join(''), flags);
 }
 if (typeof first === 'string') {
   return tag;
 } else {
   flags = void 0;  // Should this be '' ?
   return tag(first, ...args);
 }
   }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Example of real world usage of function bind syntax

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew 
Robb

 ​​I would be significantly less excited about it if this happens. The ability 
 to pass around lightly bound references to methods is a big deal imo and a 
 large part of the value in this proposal.

Definitely agree. Being able to do `foo.map(::this.bar)` is really great, and 
even `const extracted = ::foo.bar` is nothing to sneeze at.

I know there's a thread on the issue tracker where a few vocal voices are 
complaining that they want partial application syntax and bikeshedding on 
various operator forms related to that, but I don't think that should 
discourage the excellent benefits that you're giving to everyone but those few. 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Example of real world usage of function bind syntax

[Domenic Denicola]

I don’t think we should make it easier to shoot yourself in the foot by 
auto-binding methods (and thus creating new copies of the method for every 
instance of the class).

From: Matthew Robb [mailto:matthewwr...@gmail.com]
Sent: Thursday, June 11, 2015 14:16
To: Jordan Harband
Cc: Domenic Denicola; Kevin Smith; es-discuss
Subject: Re: Example of real world usage of function bind syntax

Here's a cool trick I found using this bind syntax today: Babel 
REPLhttp://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falseplayground=falsecode=class%20Foo%20%7B%0A%20%20bar%20%3D%20%3A%3Athis.bar%3B%0A%20%20bar()%7B%20%20%7D%0A%7D

But it lead me to think that class methods could have `::` prefixed onto them 
to suggest that they be lightly bound method references:

class X {
  ::Y() {  }
}


- Matthew Robb

On Thu, Jun 11, 2015 at 11:56 AM, Jordan Harband 
ljh...@gmail.commailto:ljh...@gmail.com wrote:
I find the call form of the operator (`a::b()`) very useful on its own.

However, I think the main question is, will shipping the prefixed bind or 
prefixed call forms of the operator (`::a.b`, `::a.b()`), and/or the bind form 
of the operator (`a::b`), definitely preclude future extension with partial 
application, etc, or can those still be worked in somehow? If there's a way to 
include all four forms and leave open the future possibility of extension, I 
think, as Domenic points out, that we would see a lot of value from the bind 
and prefix forms as well.


On Thursday, June 11, 2015, Domenic Denicola 
d...@domenic.memailto:d...@domenic.me wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew 
Robb

 ​​I would be significantly less excited about it if this happens. The ability 
 to pass around lightly bound references to methods is a big deal imo and a 
 large part of the value in this proposal.

Definitely agree. Being able to do `foo.map(::this.bar)` is really great, and 
even `const extracted = ::foo.bar` is nothing to sneeze at.

I know there's a thread on the issue tracker where a few vocal voices are 
complaining that they want partial application syntax and bikeshedding on 
various operator forms related to that, but I don't think that should 
discourage the excellent benefits that you're giving to everyone but those few.
___
es-discuss mailing list
es-discuss@mozilla.orgmailto: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: Fixing `Promise.resolve()`

[Domenic Denicola]

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] 

 I don't think we discussed the possibility of Promise subclasses with 
 different promise signatures at the May meeting; we mainly focused on the 
 expectation that SubPromise.resolve(x) should yield an instance of SubPromise.

Yeah, and to be clear, I generally agree with this. My LabeledPromise example 
adheres to this. Other examples in related threads have been setting @@species 
to an entirely new constructor (e.g. to Promise itself), which is very strange 
to me. If you do that, you deserve whatever weirdness you might get, IMO. From 
the beginning, @@species has been about constructor signature modification.

 But I see your logic, indirecting through species provides a way for 
 subclasses to to change their constructor signature and still work correctly 
 with the other inherited Promise static methods. 

Any thoughts on Array.of and Array.from?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Fixing `Promise.resolve()`

[Domenic Denicola]

Yes, I read that thread and still stand by my position.

From: canan...@gmail.com [mailto:canan...@gmail.com] On Behalf Of C. Scott 
Ananian
Sent: Wednesday, June 10, 2015 11:39
To: Domenic Denicola
Cc: Allen Wirfs-Brock; Axel Rauschmayer; Mark S. Miller; es-discuss list
Subject: Re: Fixing `Promise.resolve()`

@Domenic: please see the previous discussion at 
https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50 
since there is much more discussion back-and-forth there.

And you are correct about Promise.reject; Allen is proposing to remove the 
@@species from that method as well.

The changes to `Promise.resolve` are needed to make other use cases work 
properly (see that other thread).  It seems that your particular use case could 
be better handled by overriding `LabelledPromise.resolve` to take an additional 
label argument.

Your understanding of @@species seems to be different from the use cases 
envisioned by the smalltalk concept named species, although it's an interesting 
idea in its own right.  You should probably call it something like custom 
constructors, though, to differentiate it from the smalltalk species, which 
is used in the smalltalk world to describe two related things (1) the generic 
type of the object, for type tests, and (2) the derived type which 
instance-transformation methods should yield.[*]  In smalltalk (as I understand 
it) custom constructors are not part of the design.
  --scott

[*] Answer the preferred class for reconstructing the receiver. For example,  
collections create new collections whenever enumeration messages such as 
collect: or select: are invoked. The new kind of collection is determined by 
the species of the original collection. Species and class are not always the  
same. For example, the species of Interval is Array. 
http://forum.world.st/species-td3374278.html

On Wed, Jun 10, 2015 at 11:22 AM, Domenic Denicola 
d...@domenic.memailto:d...@domenic.me wrote:
Allen, that change seems wrong. I thought we were only changing the IsPromise 
steps. The actual construction should still go through species. If nothing 
else, it should do so for consistency with reject.

The motivation of @@species, as I understood it, was to allow alternate 
subclass constructor signatures (originally for Array and TypedArray, but 
Promise can benefit as well). It’s understandable to not involve @@species when 
doing weak type-tests. But any time you construct a promise instance, you 
should go through @@species, instead of the constructor directly.

Some example usages:

- Creating a LabeledPromise subclass (for better debugging, like RSVP's 
promises + Ember promise inspector) whose constructor signature is `new 
LabeledPromise(label, executor)`
- Creating a SaneArray subclass whose constructor signature is `new 
SaneArray(...elements)` without the special-case for a single argument.
- A more complicated usage in a proposed Element/HTMLElement/MyCustomElement 
hierarchy [1], to allow custom elements to have custom constructor signatures 
but still work well with various element-creating parts of the platform.

The LabeledPromise case will, as currently specified, work great. 
LabeledPromise has a custom `LabeledPromise[Symbol.species](executor)` which 
basically does `return new this(derived promise, executor)`. Then it 
doesn't have to override `.resolve`, `.reject`, `.all`, or `.then`. However, 
with your change, `.resolve` will no longer work correctly, even though 
`.reject` will.

However, the SaneArray case actually will only work for the instance methods, 
which use ArraySpeciesCreate. In contrast, Array.of and Array.from use 
Construct(C, len). That seems like a bug in the spec?

[1]: 
https://github.com/domenic/element-constructors/blob/cdfe5a1d865e25d265074418df7918fda959e403/element-constructors.js#L101-L107
___
es-discuss mailing list
es-discuss@mozilla.orgmailto: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: Fixing `Promise.resolve()`

[Domenic Denicola]

Regardless of whether or not you agree, that was the original motivation for 
its introduction.

From: canan...@gmail.com [mailto:canan...@gmail.com] On Behalf Of C. Scott 
Ananian
Sent: Wednesday, June 10, 2015 11:45
To: Domenic Denicola
Cc: Allen Wirfs-Brock; Mark S. Miller; es-discuss list
Subject: Re: Fixing `Promise.resolve()`

I don't agree that @@species is useful at all for changing constructor 
signatures, since there is no closure argument.

If we had dynamically scoped variables, then:
```
  LabelledPromise[Symbol.species] = function() { return 
LabelledPromise.bind(label/*dynamically scoped*/); };
  function() {
let label = foo;
return LabelledPromise.resolve(x);
  }
```
would indeed be very interesting.  But in the absence of some sort of closure, 
the only way you can make @@species into a custom constructor is for odd 
special cases where you are just rearranging deck chairs.

Why not:
 ```
class LabelledPromise {
  constructor(exec, label) {
super(exec);
this.label = label === undefined ? derived promise : label;
  }
}
```
  --scott

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

RE: Fixing `Promise.resolve()`

[Domenic Denicola]

Allen, that change seems wrong. I thought we were only changing the IsPromise 
steps. The actual construction should still go through species. If nothing 
else, it should do so for consistency with reject.

The motivation of @@species, as I understood it, was to allow alternate 
subclass constructor signatures (originally for Array and TypedArray, but 
Promise can benefit as well). It’s understandable to not involve @@species when 
doing weak type-tests. But any time you construct a promise instance, you 
should go through @@species, instead of the constructor directly.

Some example usages:

- Creating a LabeledPromise subclass (for better debugging, like RSVP's 
promises + Ember promise inspector) whose constructor signature is `new 
LabeledPromise(label, executor)`
- Creating a SaneArray subclass whose constructor signature is `new 
SaneArray(...elements)` without the special-case for a single argument.
- A more complicated usage in a proposed Element/HTMLElement/MyCustomElement 
hierarchy [1], to allow custom elements to have custom constructor signatures 
but still work well with various element-creating parts of the platform.

The LabeledPromise case will, as currently specified, work great. 
LabeledPromise has a custom `LabeledPromise[Symbol.species](executor)` which 
basically does `return new this(derived promise, executor)`. Then it 
doesn't have to override `.resolve`, `.reject`, `.all`, or `.then`. However, 
with your change, `.resolve` will no longer work correctly, even though 
`.reject` will.

However, the SaneArray case actually will only work for the instance methods, 
which use ArraySpeciesCreate. In contrast, Array.of and Array.from use 
Construct(C, len). That seems like a bug in the spec?

[1]: 
https://github.com/domenic/element-constructors/blob/cdfe5a1d865e25d265074418df7918fda959e403/element-constructors.js#L101-L107
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Promise sub-class: super((resolve, reject) = this) ?

[Domenic Denicola]

Hmm I am pretty sure Babel et al. are correct here in not allowing this. The 
super call needs to *finish* before you can use `this`. Chrome also works this 
way.

The correct workaround is

```js
let resolve, reject;
super((a, b) = {
  resolve = a;
  reject = b;
});

// use this
```

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

RE: Actual WeakSet Use Cases

[Domenic Denicola]

WeakSets are perfect for branding and are how I would expect web platform class 
branding to be explained.

```js
const foos = new WeakSet();

class Foo {
  constructor() {
foos.add(this);
  }
  
  method() {
if (!foos.has(this)) {
  throw new TypeError(Foo.prototype.method called on an incompatible 
object!);
}
  }
}
```

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

RE: Maybe we need a reflect API to iterate over instance members

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gray Zhang

 I’m just wondering is there any reason that Reflect API is not suitable to 
 provide such functionality?

Reflect currently contains only methods which correspond to proxy traps. There 
has been talk of extending it beyond that, but making that first step is going 
to be a hurdle for whoever’s proposing it to extend it. A better place for such 
methods might be Object.* or some new module or global.

However, in the end, what you need to do to get something into the language is 
to prove that it's a common enough need that it's worth adding complexity to 
the spec and implementations. This thread is very far from doing that. A better 
start would be surveying open-source code to find usages of this kind of 
functionality.
 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: How can I synchronously determine a JavaScript Promise's state?

[Domenic Denicola]

I will repeat to you what I said on Specifiction:

 To get a standard API for this, you'll need to convince the JavaScript 
 standard committee, as well as the browser vendors, that your use case is 
 widespread and important enough to be worth the standardization and 
 implementation burden, and that it cannot be achieved in any other possible 
 way.

 So ... go!

Looking forward to your use cases, preferably with examples showing code in 
popular libraries or apps that would benefit to illustrate how wide-spread 
those use cases are.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: import ModuleSpecifier

[Domenic Denicola]

It is syntactically valid, but there is no specification for what the module 
specifier string should contain. Traceur has one rule, and if you’re using 
Traceur you need to follow Traceur’s rules. I’m sure other transpilers have 
their own chosen rules.

In a hypothetical future where browsers have a module loader, they will have 
their own rule. Similarly, io.js will have its own.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark 
Volkmann
Sent: Sunday, May 31, 2015 17:21
To: es-discuss@mozilla.org
Subject: import ModuleSpecifier

I was under the impression that the following is a valid import statement:

import {something} from './somefile';

I know this used to work in Traceur. However, in the latest version of Traceur 
I have to include a file extension like this for it to work:

import {something} from './somefile.js';

I don't see any place in the spec. where it describes whether ModuleSpecifier 
should include a file extension. Maybe I just missed it. Is Traceur correct to 
require it?

--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: import ModuleSpecifier

[Domenic Denicola]

Yes, in theory. However, browsers are more likely to wait until there’s a 
standard for browser module loaders before shipping modules, in order to avoid 
such divergent behavior.

But, I doubt that io.js, Traceur, etc. will follow the browser-loader standard. 
For example io.js will likely have a loader that is more in line with their 
current ES5 one, and transpilers will probably contain a way of switching 
between io.js and browser behaviors, at the bare minimum.

From: Mark Volkmann [mailto:r.mark.volkm...@gmail.com]
Sent: Sunday, May 31, 2015 19:37
To: Domenic Denicola
Cc: es-discuss@mozilla.org
Subject: Re: import ModuleSpecifier

Are you saying that in the future each browser can have its own rule for module 
specifier strings?

On Sun, May 31, 2015 at 4:31 PM, Domenic Denicola 
d...@domenic.memailto:d...@domenic.me wrote:
It is syntactically valid, but there is no specification for what the module 
specifier string should contain. Traceur has one rule, and if you’re using 
Traceur you need to follow Traceur’s rules. I’m sure other transpilers have 
their own chosen rules.

In a hypothetical future where browsers have a module loader, they will have 
their own rule. Similarly, io.js will have its own.

From: es-discuss 
[mailto:es-discuss-boun...@mozilla.orgmailto:es-discuss-boun...@mozilla.org] 
On Behalf Of Mark Volkmann
Sent: Sunday, May 31, 2015 17:21
To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: import ModuleSpecifier

I was under the impression that the following is a valid import statement:

import {something} from './somefile';

I know this used to work in Traceur. However, in the latest version of Traceur 
I have to include a file extension like this for it to work:

import {something} from './somefile.js';

I don't see any place in the spec. where it describes whether ModuleSpecifier 
should include a file extension. Maybe I just missed it. Is Traceur correct to 
require it?

--
R. Mark Volkmann
Object Computing, Inc.



--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Providing object iterators beyond just Object.keys()

[Domenic Denicola]

http://lmgtfy.com/?q=site%3Aesdiscuss.org+object.values

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gijs 
Kruitbosch
Sent: Tuesday, May 26, 2015 10:33
To: es-discuss@mozilla.org
Subject: Providing object iterators beyond just Object.keys()

Hello,
When writing JS loops over objects, given the environment I'm in, I find myself 
using the gecko/spidermonkey-only Iterator() construct a lot for loops or 
array comprehensions:
for (let [key, val] of Iterator(plainJSObject)) {
   // do stuff with both key and val
}
It seems the plan is to remove Iterator() (cf. 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator
 ).
Are there plans to add things like Object.values() (to produce 
Object.keys(obj).map(k = obj[k]) ) or Object.iterator (Object.keys(obj).map(k 
= [k, obj[k]])) so as to enable such usecases to be written easily in ES7 or 
later? Obviously I can create my own iterator, but it starts to get tedious if 
I need to do this in every file where I need to iterate over an object's own 
(enumerable) properties...
(using Maps here is difficult because writing hardcoded nested structures of 
Maps is not nearly as neat as doing the same with Objects)
Gijs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: let function

[Domenic Denicola]

They can, in fact, be scoped in a for loop.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andrea 
Giammarchi
Sent: Thursday, May 14, 2015 14:53
To: Kevin Smith
Cc: es-discuss@mozilla.org
Subject: Re: let function

I guess 'cause that cannot be scoped, let's say in a for loop ... but yeah, I 
think that's not the most needed thing in the language right now, yet another 
shortcut with double reserved words one after the other

Regards

On Thu, May 14, 2015 at 7:45 PM, Kevin Smith 
zenpars...@gmail.commailto:zenpars...@gmail.com wrote:
Why not use a function declaration instead?

On Thu, May 14, 2015 at 2:37 PM Alexander Jones 
a...@weej.commailto:a...@weej.com wrote:
Propose adding support for

let function foo() {};

which would have the equivalence of:

let foo = function foo() {};

The idea is to support the normal scoping of let, but without forcing you to 
repeat yourself when naming the function, whilst still having the function's 
name property be set.

This would trivially extend to const and var. Also, possibly class.

Thanks

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

___
es-discuss mailing list
es-discuss@mozilla.orgmailto: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: let function

[Domenic Denicola]

Not all browsers have implemented the spec yet. But you should read the spec 
before proposing changes to it!

From: Alexander Jones [mailto:a...@weej.com]
Sent: Thursday, May 14, 2015 15:16
To: Domenic Denicola
Cc: Andrea Giammarchi; Kevin Smith; es-discuss@mozilla.org
Subject: Re: let function

That's not what I see, in strict mode at least, which I assume most people 
consider de facto by now!

From V8:

SyntaxError: In strict mode code, functions can only be declared at top 
level or immediately within another function.

Similar error from SpiderMonkey.

On Thursday, May 14, 2015, Domenic Denicola 
d...@domenic.memailto:d...@domenic.me wrote:
They can, in fact, be scoped in a for loop.

From: es-discuss 
[mailto:es-discuss-boun...@mozilla.orgjavascript:_e(%7B%7D,'cvml','es-discuss-boun...@mozilla.org');]
 On Behalf Of Andrea Giammarchi
Sent: Thursday, May 14, 2015 14:53
To: Kevin Smith
Cc: 
es-discuss@mozilla.orgjavascript:_e(%7B%7D,'cvml','es-discuss@mozilla.org');
Subject: Re: let function

I guess 'cause that cannot be scoped, let's say in a for loop ... but yeah, I 
think that's not the most needed thing in the language right now, yet another 
shortcut with double reserved words one after the other

Regards

On Thu, May 14, 2015 at 7:45 PM, Kevin Smith 
zenpars...@gmail.comjavascript:_e(%7B%7D,'cvml','zenpars...@gmail.com'); 
wrote:
Why not use a function declaration instead?

On Thu, May 14, 2015 at 2:37 PM Alexander Jones 
a...@weej.comjavascript:_e(%7B%7D,'cvml','a...@weej.com'); wrote:
Propose adding support for

let function foo() {};

which would have the equivalence of:

let foo = function foo() {};

The idea is to support the normal scoping of let, but without forcing you to 
repeat yourself when naming the function, whilst still having the function's 
name property be set.

This would trivially extend to const and var. Also, possibly class.

Thanks

___
es-discuss mailing list
es-discuss@mozilla.orgjavascript:_e(%7B%7D,'cvml','es-discuss@mozilla.org');
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.orgjavascript:_e(%7B%7D,'cvml','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: Streams and Observables

[Domenic Denicola]

See my response when you asked this question a month ago: 
https://esdiscuss.org/topic/promises-vs-streams#content-5 Especially, follow 
the links.

To correct a few misconceptions:

 streams analogous to a list of values

there are many things in the async/plural category, not just streams

 Async generator (https://github.com/jhusain/asyncgenerator) returns Observable

Or it could return an async generator object 
(https://github.com/zenparsing/async-iteration/). The async generator - 
Observable proposal is just a proposal.

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

Re: *.empty Idea

[Domenic Denicola]

It's fine to propose something to make maps immutable. Just don't call it 
Object.freeze.






On Thu, Apr 30, 2015 at 11:56 AM -0700, C. Scott Ananian 
ecmascr...@cscott.netmailto:ecmascr...@cscott.net wrote:

Can you make an alternative proposal that still preserves the essential 
property of Object.freeze on collections -- that is to say, preserves object 
identity while preventing future writes?

Here's another strawman:
 Add [[Immutable]] to the arguments of OrdinaryCreateFromConstructor in step 
 2 of 23.1.1.1 (Map) and 23.2.1.1 (Set)
 Add If the [[Immutable]] internal slot of M is true, throw a TypeError 
 exception between steps 3 and 4 of 23.1.3.1 (Map.prototype.clear), 23.1.3.3 
 (Map.prototype.delete), 23.1.3.9 (Map.prototype.set), 23.2.3.1 
 (Set.prototype.add), 23.2.3.2 (Set.prototype.clear), and 23.2.3.4 
 (Set.prototype.delete).
 Add `Map.prototype.makeReadOnly()` and `Set.prototype.makeReadOnly()` methods 
 with the definition:
  1. Let M be the this value.
  2. If Type(M) is not Object, throw a TypeError exception
  3. If M does not have a [[Immutable]] internal slot, throw a TypeError 
 exception
  4. Set the [[Immutable]] internal slot of M to true.

This is somewhat awkward and ad-hoc, but it won't break ES6 code.

I am concerned about this issue in part because as written is seems to be 
impossible to prevent writes to Map.  If you subclass it, freeze it, override 
set/delete/etc it is still possible to mutate the map using `Map.set.call(m, 
'a', 'b');`.  And there is no way for use code to get at the [[MapData]] slot 
to protect it.
  --scott


On Thu, Apr 30, 2015 at 2:42 PM, C. Scott Ananian 
ecmascr...@cscott.netmailto:ecmascr...@cscott.net wrote:
On Thu, Apr 30, 2015 at 2:22 PM, Mark S. Miller 
erig...@google.commailto:erig...@google.com wrote:
It would also not be compatible with ES6 code. SES will be freezing Map, Set, 
WeakMap, and WeakSet instances in order to tamper proof their API. I expect 
many others will as well. Having this freeze then cause a non-mutability in ES7 
will break all such ES6 code. This is a non-starter all around.

Couldn't SES use Object.seal/Object.preventExtensions/Object.defineProperty to 
perform tamper-proofing without flipping the frozen bit?
 --scott

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

RE: Subclassing ES6 objects with ES5 syntax.

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C. Scott 
Ananian

 But in the code given previously, I've used `Object.setPrototypeOf` to 
 effectively change the type of the object -- but [[PromiseConstructor]] 
 doesn't follow along.

That is exactly the kind of tampering that the unforgable 
[[PromiseConstructor]] mechanism is meant to prevent.

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

Re: Subclassing ES6 objects with ES5 syntax.

[Domenic Denicola]

It's possible Reflect.construct has introduced a security hole that was not 
present before the recent instantiation reform. Hopefully Mark can comment more.






On Sat, Apr 25, 2015 at 9:52 PM -0700, C. Scott Ananian 
ecmascr...@cscott.netmailto:ecmascr...@cscott.net wrote:

On Sat, Apr 25, 2015 at 6:58 PM, Kevin Smith 
zenpars...@gmail.commailto:zenpars...@gmail.com wrote:
I think I'd rather see `Promise.resolve` changed to use `this.constructor` 
instead of `this.[[PromiseConstructor]]`, like every other Promise-related 
method.  Can someone who feels strongly otherwise give me the use case for 
`[[PromiseConstructor]]` existing?

I shouldn't have written `this.constructor` here.  I think looking at the 
object's prototype would be preferable.

Promise.resolve, executed on a constructor C, with argument x, should only 
return x if x was created by C.[[Construct]].  Otherwise it should create an 
instance of C which is resolved with x.

was created by C.[[Construct]] with NewTarget equal to C is roughly how it is 
written currently.  But I think should only return x if x is an instanceof C 
(or if the prototype of C is exactly C.prototype) would be the most logical 
behavior, since:

If we used x.constructor to determine the actual constructor, then someone 
could just change the constructor property for x and fool someone who wrote 
C.resolve(x) and expected to get an instance of C back.
It would be an unreliable, unsound conversion function.

I don't think this argument holds water since:

x = Reflect.construct(Promise, x, C);

is another fine way to fool someone who wrote C.resolve(x) and expected to 
get an instance of C back.

What's more, I can then do:

Object.setPrototype(x, SomeArbitraryThing);

and still fool C.resolve, and now x behaves nothing like a Promise (much less a 
C).

So we've got an unreliable, unsound conversion function.  What is it good for?

If our conversion is inherently unsound, we might as well have it preserve 
duck typing.  If it's currently quacking like a duck (that is, x.prototype = 
Duck.prototype), then let's just call it a duck and be done with it.   Adding 
complexity to try to preserve soundness isn't actually working.

Again: but maybe I'm wrong.  Can someone with a security-sensitive application 
explain how Promise.resolve is actually the right thing for them?
  --scott

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

RE: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[Domenic Denicola]

Indeed, there is no built-in facility for bundling since as explained in this 
thread that will actually slow down your performance, and there’s no desire to 
include an antipattern in the language.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Eric B
Sent: Thursday, April 23, 2015 10:25
To: Frankie Bagnardi; Matthew Phillips
Cc: es-discuss
Subject: Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

So just to clarify, when browsers support es6 modules we will still need some 
extra library to bundle the modules?  This would mean es6 modules are only a 
syntactical addition and not something functional?

On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi 
f.bagna...@gmail.commailto:f.bagna...@gmail.com wrote:
Matthew, there are already tools for es6 modules + bundling (e.g. babel + 
webpack), or converting es6 modules to AMD (e.g. 
babelhttps://babeljs.io/docs/usage/modules/).



On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips 
matt...@bitovi.commailto:matt...@bitovi.com wrote:

Can you clarify what you mean about bundling? Unless I've missed something, the 
ES6 module system does not have a story for bundling at all. Of course formats 
can be invented in userland but I'm not sure that they are any easier to 
implement than say AMD's.  I might have missed something though, looking 
forward to your reply.

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

___
es-discuss mailing list
es-discuss@mozilla.orgmailto: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: Putting `global` reference in specs

[Domenic Denicola]

One thing I'm surprised nobody has brought up yet is that global would be an 
incorrect name in the case of browsers. The actual global object is not (and 
must never be) directly accessible. Instead you get a window proxy when you use 
`window`, `self`, `this`, etc.

As such I think our best bet is for server-side JS runtimes to use `self` or 
`window`.

The latter isn't as crazy as it sounds: just start adding phrases to the ES 
spec like all JavaScript code runs within a certain context, called a 
_window_, which has a corresponding _window object_. In some runtimes the 
window object will be equivalent to the global object, but not always. Scripts 
run within _window scope_, whereas modules run in their own lexical context. 
The value of **this** in window scope is the window object.

It's not as if `window` actually means window anymore, given tabs and iframes 
and frames. We might as well move it into the set of terms like realm or 
vat or environment that are more abstract than real.

-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Anne van 
Kesteren
Sent: Friday, April 17, 2015 11:19
To: Andrea Giammarchi
Cc: es-discuss@mozilla.org
Subject: Re: Putting `global` reference in specs

On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:
 So I'd say we should not have `self` (if stays on global and Worker I 
 don't actually care) and add a `global` that nobody needs explanation 
 to understand what it is in JavaScript

Indeed, three ways to reference the global object is not nearly enough.


--
https://annevankesteren.nl/
___
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: Are ES6 modules in browsers going to get loaded level-by-level?

[Domenic Denicola]

From: John Barton [mailto:johnjbar...@google.com] 

 But the push scenario in your first paragraph would not use the cache either.

Yeah, that's what I was alluding to with the most naïve comment.

  one or the other has to send its information at the outset of a import 
request, or 

One way of doing this I came up with off the top of my head is to add some kind 
of dependency graph version or hash to the query string. I.e. script 
type=module src=entry.js?1234/script. The server can then assume that 
the client has in its cache version 1234 of the dependency graph, and can push 
the incremental updates since then (i.e. added or modified files). If parts of 
the cache were evicted, so that the versioning signal is not entirely accurate, 
then the penalty is not so bad, as you just fall back to the normal loading 
process for the evicted subset.

But I feel pretty silly speculating here as I'm not an expert on HTTP/2 
techniques, and there are probably other methods that are better in various 
ways.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Are ES6 modules in browsers going to get loaded level-by-level?

[Domenic Denicola]

 Is there any mean in sight, that will allow us to serve
 them as fast as we can serve hundreds of bundled and minimized CJS
 modules now?

Yes. Any browser which implements the ES6 module loader (none of them right 
now) will also be a browser that implements HTTP/2 (all of them right now). 
HTTP/2 server push would allow you to respond to a single request for 
entry.js (e.g. from `script type=module src=entry.js/script`) with 
responses for all modules in the entire dependency graph, prioritized according 
to their level in the graph, all over a single TCP connection.

This is just the most naïve strategy I could think of with HTTP/2. There are 
more interesting ones too.

It's also important to note that bundling is an antipattern in the HTTP/2 
world, as it prevents incremental cache updates by invalidating the entire 
bundle graph when you change a single file, and does not allow relative 
prioritization of individual files.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Could we make %ArrayPrototype%'s [[DefineOwnProperty]] throw or no-op for numeric keys?

[Domenic Denicola]

Just an idle thought:

Many of the spec-compliance bugs in engines' array implementations over the 
last couple years have had to do with handling what happens when you e.g. 
install getters or setters on %ArrayPrototype%. I've been told that handling 
this case adds lots of complexity to the implementations and their 
optimizations.

Would it be worthwhile to explore making this impossible? Since 
%ArrayPrototype% is an exotic object anyway, we could give it a custom 
[[DefineOwnProperty]] that behaves similarly to that of array exotic objects, 
but disallows defining numeric keys. I guess this comes down to a few questions:

- Would this actually give gains for implementers? My information here is 
secondhand and inferred.
- Would the implementation complexity introduced by this change (separate 
exotic object types for arrays vs. %ArrayPrototype%) be worth the gains 
elsewhere, or is it just trading one weirdness for another?
- Is this feasibly web-compatible? (i.e. worth trying?)

Curious what implementers think.

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

RE: the Great Tooling Revolution

[Domenic Denicola]

This was discussed briefly at the previous meeting, perhaps un-minuted.

The basic plan is to develop the spec on GitHub, using [Ecmarkup][] and 
[Ecmarkdown][]. It will take pull requests, have a master branch that you can 
view (and implementers should view, to see any bug fixes made since the Ecma 
version), etc.

Brian did a prototype conversion a while back, based on an older draft and an 
older dialect of Ecmarkup (no Ecmarkdown); you can find that at 
https://github.com/bterlson/ecmascript. I believe the current status it that 
we're waiting for the final GA-submitted version before doing the real 
conversion, since Allen is making editorial tweaks and bug-fixes up until the 
deadine. Once that's done we'll use some mutated version of Jason's 
[converter][] and start iterating and tweaking from there.

Unlike the current process, the post-ES2015 spec process requires two shipping 
implementations before a feature is integrated into the spec. While we're 
waiting for that, we anticipate proposal documents to prepare for integration 
by being written as Ecmarkup/Ecmarkdown spec deltas, with their own issue 
trackers. For an example of this, see [Object.observe][].

There's been less discussion about what to do with the issues list: GitHub 
issues vs. bugs.ecmascript.org. At the very least I would hope that we welcome 
community issues on GitHub, even if bugs.ecmascript.org stays active.


[Ecmarkup]: https://bterlson.github.io/ecmarkup/
[Ecmarkdown]: https://github.com/domenic/ecmarkdown
[converter]: https://github.com/jorendorff/es-spec-html/
[Object.observe]: https://arv.github.io/ecmascript-object-observe/

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

RE: the Great Tooling Revolution

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Michael 
Dyck

 So not as git branches of the spec?

I mean, I guess they could if they want, but that seems like a lot of work for 
the spec writer to be constantly rebasing. Better to only do the branch when 
it's time for a pull request, I'd imagine.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: the Great Tooling Revolution

[Domenic Denicola]

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] 

 However, that is a lot of infrastructure work and I don’t think we should let 
it to get in the way of shipping our first yearly update.

Thanks for pointing this out. I agree that we may be over-optimistic in 
thinking the new tooling will be completely production-ready in a year, and if 
it indeed falls short of that mark we should not let that be a blocker. I'm 
hopeful we can in fact accomplish it all in a year, but, Hofstadter's Law etc.

 There is already a bugs.ecmascript.org  “product” for ES7 and it is open to 
 community issues.  We should certainly try moving towards GitHub issues for 
 individual post ES7 feature proposals and it that works out well perhaps we 
 can migrate the the ES7 bugs.ecmascript.org issues to github issues.

Sounds like a plan!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Default `this` value for static promise functions

[Domenic Denicola]

Or just throw:

return getError().then(r = { throw r; })

 -Original Message-
 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
 Brendan Eich
 Sent: Tuesday, April 7, 2015 13:47
 To: a.d.be...@web.de
 Cc: es-discuss@mozilla.org
 Subject: Re: Default `this` value for static promise functions
 
 a.d.be...@web.de wrote:
  Hi,
  I've just got bitten by
 
   return getError().then(Promise.reject);
 
  where `reject` threw an error that its `this` value was not a Promise
 constructor.
 
  Would it help to make the `C` constructor (in Promise.resolve,
 Promise.reject, Promise.all, Promise.race algorithms) default to `Promise`
 when no `this` value is supplied (throw only if it's there, but not an object 
 and
 constructor function)?
 
 No, because as you suggested:
 
  Or is this considered to be too error-prone with Promise subclassing, where
 `.then(MyCustomPromise.reject)` would not work as expected (fail silently)?
 
 Probably the best solution is an arrow:
 
  return getError().then(r =  Promise.reject(r));
 
 
 /be
 ___
 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: last value from iterator

[Domenic Denicola]

I don't think it's good to think of the value sent with `done: true` as one of 
the values. It's in a different category, and not part of the yielded sequence.

From: Mark Volkmannmailto:r.mark.volkm...@gmail.com
Sent: ‎2015-‎04-‎05 18:43
To: Allen Wirfs-Brockmailto:al...@wirfs-brock.com
Cc: es-discuss listmailto:es-discuss@mozilla.org
Subject: Re: last value from iterator

Thanks, that helps. I had been thinking that for-of was a model for how 
iterators should be consumed.

When implementing any kind of iterator (generator or not), it seems important 
to recognize that if you choose to return a value with done set to true, you 
are precluding the use of for-of with that iterator (assuming you want all the 
values).

On Sun, Apr 5, 2015 at 11:40 AM, Allen Wirfs-Brock 
al...@wirfs-brock.commailto:al...@wirfs-brock.com wrote:

On Apr 5, 2015, at 6:04 AM, Mark Volkmann wrote:

I thought that when an iterator returns done: true, the value should not be 
used.

Why do you think that?  The definition of the IteratorResult interface in the 
the ES6 spec. doesn't say that.

However, if a generator function ends by returning a value, done will be true 
when that value is returned and the value should be used.

Could be used.  Whether a generator or any Iterator provides a meaningful value 
when it reach the the 'done' state depends upon its specific definition.

Given this, how can a consumer know the correct way to handle the value when 
done is true? Clearly consumers shouldn't have to be aware of whether the 
iterator is actually a generator and whether it ends by returning a value.

An Iterator does not have to be a generator to provide a 'done' state value.  
In general, If you are going to do anything other than basic iteration, such as 
is performed by for-of, you need to know about the specific Iterator you are 
using.

Allen





--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Determine if a value is Callable/Constructible

[Domenic Denicola]

I don’t think [Symbol.call] is a very good mechanism. A new syntactic form 
would make more sense.

It doesn’t seem right that you should have to introduce an observable prototype 
property just to get [[Call]] behavior. (Or a constructor property, if you 
change the syntax to `static [Symbol.call]() { … }`.)

And it raises the question of what happens when I add a [Symbol.call] property 
to other objects. What does it even mean? If I do `var obj = { prototype: { 
[Symbol.call]() { console.log(foo); } } }`, can I now call `obj()`? Is 
`typeof obj === function`? Very strange stuff. Presumably not very 
VM-friendly either, but that's just a guess.

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

RE: Determine if a value is Callable/Constructible

[Domenic Denicola]

Great to get the ball rolling. Here's some issues I'd bring up at the meeting, 
so we can get a head start:

- As discussed recently in 
https://esdiscuss.org/topic/reflect-getownpropertysymbols, right now Reflect 
only holds counterparts to the proxy traps. I think this is kind of a nice 
property. Do we want to expand Reflect into a dumping ground for all 
reflective operations? That's been implied many times on the list, but so far 
hasn't happened, from what I can see. On the other hand, I don't have any good 
ideas for where else to put these things. (Maybe Function.isConstructor? Not 
sure it scales.)

- Reflect.isCallable seems pretty pointless, when you can just do `typeof x === 
function`. YAGNI IMO. Note that it also doesn't match your earlier 
description from 
https://esdiscuss.org/topic/determine-if-a-value-is-callable-constructible#content-0,
 so it presumably doesn't solve those use cases. (But that definition can't 
really be workable, since all of the things you mention as not being callable 
are actually callable, in the same way `function f() { throw new TypeError(); 
}` is callable.)

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

RE: Determine if a value is Callable/Constructible

[Domenic Denicola]

If you made them non-callable by not implementing [[Call]], then typeof would 
no longer return function, which would be ... O_o.

 -Original Message-
 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
 Caitlin Potter
 Sent: Monday, March 30, 2015 11:25
 To: Yehuda Katz
 Cc: es-discuss@mozilla.org
 Subject: Re: Determine if a value is Callable/Constructible
 
 But in either case, these (IsCallable / IsConstructor) are pretty basic
 qualities of objects that a Reflection* api ought to be able to read into, 
 imho.
 
 What Allen is saying is that the implementation of throw if
 constructor doesn't work by not implementing [[Call]], but rather by
 implementing [[Call]] to throw, so those reflective APIs would say the wrong
 thing, and that this is observable via proxies.
 
 It’s a fair point, constructors do have a [[Call]] internal method — there’s 
 no
 reason this needs to be described this way though. Instead of the extra step
 for classConstructors in 9.2.1, class constructors could just as easily not 
 have a
 [[Call]] method at all (by default). I guess what I’m getting at is, right now
 they aren’t “really” callable, it’s just that the way their non-callable-ness 
 is
 expressed makes them appear callable (which probably should not be the
 case). Since they’re intrinsically not callable (currently), they shouldn’t be
 treated as callable.
 
 What Domenic is saying later on makes sense, the magic “call-code” method
 (should it ever exist) shouldn’t be a property of the class prototype, so a
 special syntactic form would work better (but also be kind of awful, too).
 
 
  Allen, can you say more about why you spec'ed it that way?
 
 
  
  
   On Mar 29, 2015, at 11:51 PM, Caitlin Potter caitpotte...@gmail.com
 wrote:
  
   ...
  
   Reflect.isConstructor(fn) - true if Class constructor, generator,
   or legacy (and non-builtin) function syntactic form
   Reflect.isCallable(fn) - true for pretty much any function, except
   for class constructors and a few builtins
  
   I’ve already seen another situation (node’s Buffer) where code could be
 simplified by using a ES6 class definition but where that is prevented because
 a class constructor throws when called.
  
   Just to clarify something.  Class constructors actually are “callable”.  
   You
 can observe this by the fact that Proxy allows you to install an “apply” 
 handler
 (the reification of the [[[Call]] internal method) on a class constructor.   
 The
 the fact that an object can be [[Call]]’ed is already reflected  by the typeof
 operator.  Class constructors throw when called because at the last minute
 we choose to make their [[Call]] do an explicit throw not because they aren’t
 callable.
  
   There is no intrinsic reason why we needed to mandate that class
 constructors should throw when called.  We even provided a simple and
 straight forward way (new.target===undefined) that a ES constructor body
 can use to determine whether it was called or new’ed.
  
   I think we should just drop that throws when called feature of class
 constructors..
  
   (The restriction was added to future proof for the possibility of
   inventing some other way to provide a class with distinct new/call
   behavior. I don’t think we need nor can afford to wait for the
   invention of a new mechanism which will inevitably be more complex
   than new.target, which we already have.)
  
   Allen
  
  
 
  ___
  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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Determine if a value is Callable/Constructible

[Domenic Denicola]

 It could still be identified as a “function” for compat with ES5, but the
 behaviour is different from any other sort of function, it should be
 identifiable as different.

Right, but again, I don't think the behavior is any different from `function 
f() { throw new TypeError(); }`, so whatever the test you write returns for 
classes, my position is that it should return the same thing for `f`.

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

RE: Determine if a value is Callable/Constructible

[Domenic Denicola]

The distinction you're really pointing to here is the distinction between 
user-generated throwing functions and runtime-generated ones. Both are called. 
User-generated ones you could edit the source code of and insert a `called = 
true` line first, whereas runtime-generated ones you could not. But that's not 
a real material difference in call-ability.

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

RE: Determine if a value is Callable/Constructible

[Domenic Denicola]

From: Axel Rauschmayer [mailto:a...@rauschma.de] 

 In some way, that would even be correct – depending on what you expect a 
 function to be: something callable or something constructible. Alas, there is 
 currently no simple way to distinguish “callable” and “constructible”.

Why do you say they're not callable?

Is this function callable?

function f() {
  throw new TypeError(cannot call f because you're not pretty enough);
}

what about


function f() {
  throw new TypeError(Class constructors cannot be invoked without 'new');
}

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

RE: Determine if a value is Callable/Constructible

[Domenic Denicola]

From: Kevin Smith [mailto:zenpars...@gmail.com] 

 I'd imagine that you'd re-spec [[Call]] for class constructors to basically 
 do `this[Symbol.call](...args)` instead of just throw.  It would therefore 
 only have an effect within class constructors.  Is that still weird?

At least it's explicable, but it's still pretty weird I think. I mean, we don't 
specify [[Construct]] by saying that it does `new 
this.prototype.constructor(...args)` or similar. The asymmetry is jarring.

And it's weird to have this symbol with such a generic name that doesn't work 
for anything except class syntax. I'd expect symbols to be for re-usable 
protocols... that's fuzzy intuition though, I admit, and might be contradicted 
by existing examples.

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

RE: Promises vs Streams

[Domenic Denicola]

The same argument also implies that arrays are more powerful than scalar 
values, and we should e.g. never use a number when we could instead just use a 
single-element array with a number.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boopathi 
Rajaa
Sent: Saturday, March 28, 2015 08:15
To: es-discuss@mozilla.org
Subject: Promises vs Streams

I feel this must have already been discussed but couldn't find any discussion 
threads, just trying to understand them better.

The basic doubt is that I feel promises are more like streams, and that streams 
are much more powerful than promises. With a promise you have a value or an 
exception, and with a stream, you have a list of values or an exception.

Why do we have both ? or more specifically, since we have both, when to use 
Promises and when to use Streams ? Whatever I imagine to be a Promise can be 
thought out to be solved by Streams, and sometimes whenever I use streams, it 
feels like I'm using similar API as Promises.

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

RE: Promises vs Streams

[Domenic Denicola]

Seeing as how I just produced a completely redundant message by failing to read 
the other responses before firing off my own, let me try to redeem myself with 
some more-original content.

It’s also important to realize that streams are not the only 
asynchronous-plural primitive out there. My favorite analogy is “streams are to 
asynchronous iterables as arrays are to synchronous iterables.” That is, 
streams are a specialized data structure, made to efficiently map to 
lower-level I/O syscalls while still providing a unified abstraction and being 
an instance of some general async-iteration protocol. Similarly, arrays are a 
specialized data structure, made to efficiently handle random indexed-access 
and sequential storage, while still being an instance of the general 
(synchronous) iteration protocol.

A more general overview of this entire space can be found in Kris Kowal’s 
[General Theory of Reactivity][gtor]. He explains how there's actually several 
representatives in each of the four quadrants of sync/async + singular/plural. 
(Or more generally, spatial/temporal + singular/plural.) As you might expect, 
the most-complicated quadrant (temporal + plural) has the most possible 
representatives, from async iterators to streams to observables to behaviors to 
signals.

As for what the general async iterable interface might look like, which 
streams would be a special case of (in the same way arrays are a special case 
of sync iterables), my favorite candidate at present is 
https://github.com/zenparsing/async-iteration/. It's a straightforward 
extension of the synchronous iterable interface, and matches with the GTOR's 
reasoning quite nicely. But, there's no committee consensus on this. You'll 
also notice that, similar to arrays, the more specialized type is being 
developed and shipped first (in response to a specific need of the platform), 
with its generalization following behind.

All of this, of course, doesn't change the fact that it's useful to distinguish 
between singular and plural data structures. You get many more guarantees with 
a singular data structure than you do with a plural---similarly to how you get 
more guarantees working with, say, a value of type number, than you do with a 
value of type any. These guarantees can be important for many things, from 
security invariants to simply being able to reason about the flow of your code. 
And it's also nice to be able to build one on top of the other, in the way 
streams are built on top of promises!

[gtor]: https://github.com/kriskowal/gtor/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss