Array/Generator Comprehensions in Harmony
Would array and generator comprehensions in Harmony support functions returning void (i.e. functions with either `return;` or an implicit return) being called in the AssignmentOperator part of the Comprehension statement, like a forEach combined with map, or would it throw an error, making it effectively syntactic sugar for Array.prototype.map()? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
I agree unless the properties of said object are getter-objects that return
the bound identifier from the exporting module. Of course this would
require specifying such a thing and can happen later.
What if we get rid of this "module instance object" and instead treat it as
a binding namespace? The engine would then bind the import based on the
accessed export.
import a from "b"; a.c;
Is the same as
import {c} from "b";
On Jun 12, 2014 5:38 PM, "Calvin Metcalf" wrote:
> The fact that here is a distinction between the bindings from the module
> and the instance object of the module is the issue
> On Jun 12, 2014 8:30 PM, "Kevin Smith" wrote:
>
>> So I think this argues for two actions:
>>
>> 1. Leave the syntax as-is. The "module from" syntax makes the
>> distinction between getting the module instance object, and importing
>> bindings from a module very clear.
>>
>> 2. Educate. Perhaps those of us on the list that really get modules
>> should be writing about them as well.
>>
>>
>>
>> On Thu, Jun 12, 2014 at 5:18 PM, Brian Di Palma wrote:
>>
>>> On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf
>>> wrote:
>>> > isn't the foot gun the difference between single and multiple exports,
>>> i.e.
>>>
>>> I thought it was imports that were being misused. People were writing
>>>
>>> module m from 'mymodule';
>>>
>>> m();
>>>
>>> So they treated `module` just like `import`. I'm not sure I see the
>>> logic in doing that.
>>> Did they not wonder why there were two ways to accomplish the exact same
>>> thing?
>>> As I said, I didn't find the reasoning compelling.
>>>
>>> > to import underscore you'd use
>>> >
>>> > module _ from 'underscore'
>>> >
>>> > because it is multiple methods on an object but for jquery you'd have
>>> to use
>>> >
>>> > import $ from 'jquery'
>>> >
>>> > because the root object is a function instead of an object
>>> >
>>> > On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith
>>> wrote:
>>> >>
>>> >>>
>>> >>> I was more wondering if there was anything preventing a module import
>>> >>> statement from being added later, if it was found to be a
>>> requirement.
>>> >>> I can't see any reason why it couldn't, that would also allow time
>>> for
>>> >>> bikeshedding the syntax.
>>> >>
>>> >>
>>> >> It could be added later, but to turn the question around: why should
>>> it
>>> >> be
>>> >> dropped? It has been part of the design for a very long time, it's
>>> >> currently used by many people working in the ES6 space, and it meets a
>>> >> semantic need.
>>> >>
>>> >> If you want to drop a feature this late in the game, then you need to
>>> show
>>> >> that it's one of the following:
>>> >>
>>> >> 1. Buggy
>>> >> 2. A footgun
>>> >> 3. Not useful
>>> >> 4. Future-hostile
>>> >>
>>> >> I don't see that it meets any of those requirements, do you?
>>> >
>>> > I have no strong opinions either way. I don't feel it's any of those
>>> things.
>>> >
>>> > The argument that was given was that people were confused by it and
>>> > were using it like an `import` statement.
>>> > I said to Eric via Twitter that if people were building incorrect
>>> > compilers and modules then they will eventually learn the error of
>>> > their assumptions.
>>> >
>>> > To me the argument didn't seem that strong, the native implementations
>>> > will be correct and people will correct their broken code.
>>> >
>>> > I'm not supporting the removal. I simply don't think it's a
>>> catastrophe.
>>> >
>>> >>
>>> >> 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
Re: Re: Rationale for dropping ModuleImport syntax?
> The fact that here is a distinction between the bindings from the module > and the instance object of the module is the issue > But that distinction has always been central to the design. A module is a collection of named bindings. The default thing is an optimization feature, not the core. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 5:30 PM, Kevin Smith wrote: So I think this argues for two actions: > > 1. Leave the syntax as-is. The "module from" syntax makes the > distinction between getting the module instance object, and importing > bindings from a module very clear. > If the goal is community adoption, I think this is probably the best option. It’s too late to reopen the discussion of import x from "x" changing to have syntax that better supports multiple export, and I really dislike the implications of dropping module from at this point in the process. 2. Educate. Perhaps those of us on the list that really get modules > should be writing about them as well. > I’d prefer *evangelizing* more than *educating*. I’d like to see more direct attempts to engage with the proponents of CommonJS and AMD to see where their comfort level is now. Some of them have prematurely written off ES6 modules (IMO), but the larger community (particularly around Node / browserify) just doesn’t understand the feature, and therefore can’t give meaningful feedback for or against it – or what should change – yet. F ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
The fact that here is a distinction between the bindings from the module and the instance object of the module is the issue On Jun 12, 2014 8:30 PM, "Kevin Smith" wrote: > So I think this argues for two actions: > > 1. Leave the syntax as-is. The "module from" syntax makes the > distinction between getting the module instance object, and importing > bindings from a module very clear. > > 2. Educate. Perhaps those of us on the list that really get modules > should be writing about them as well. > > > > On Thu, Jun 12, 2014 at 5:18 PM, Brian Di Palma wrote: > >> On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf >> wrote: >> > isn't the foot gun the difference between single and multiple exports, >> i.e. >> >> I thought it was imports that were being misused. People were writing >> >> module m from 'mymodule'; >> >> m(); >> >> So they treated `module` just like `import`. I'm not sure I see the >> logic in doing that. >> Did they not wonder why there were two ways to accomplish the exact same >> thing? >> As I said, I didn't find the reasoning compelling. >> >> > to import underscore you'd use >> > >> > module _ from 'underscore' >> > >> > because it is multiple methods on an object but for jquery you'd have >> to use >> > >> > import $ from 'jquery' >> > >> > because the root object is a function instead of an object >> > >> > On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith >> wrote: >> >> >> >>> >> >>> I was more wondering if there was anything preventing a module import >> >>> statement from being added later, if it was found to be a requirement. >> >>> I can't see any reason why it couldn't, that would also allow time for >> >>> bikeshedding the syntax. >> >> >> >> >> >> It could be added later, but to turn the question around: why should >> it >> >> be >> >> dropped? It has been part of the design for a very long time, it's >> >> currently used by many people working in the ES6 space, and it meets a >> >> semantic need. >> >> >> >> If you want to drop a feature this late in the game, then you need to >> show >> >> that it's one of the following: >> >> >> >> 1. Buggy >> >> 2. A footgun >> >> 3. Not useful >> >> 4. Future-hostile >> >> >> >> I don't see that it meets any of those requirements, do you? >> > >> > I have no strong opinions either way. I don't feel it's any of those >> things. >> > >> > The argument that was given was that people were confused by it and >> > were using it like an `import` statement. >> > I said to Eric via Twitter that if people were building incorrect >> > compilers and modules then they will eventually learn the error of >> > their assumptions. >> > >> > To me the argument didn't seem that strong, the native implementations >> > will be correct and people will correct their broken code. >> > >> > I'm not supporting the removal. I simply don't think it's a catastrophe. >> > >> >> >> >> 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
Re: Re: Rationale for dropping ModuleImport syntax?
So I think this argues for two actions: 1. Leave the syntax as-is. The "module from" syntax makes the distinction between getting the module instance object, and importing bindings from a module very clear. 2. Educate. Perhaps those of us on the list that really get modules should be writing about them as well. On Thu, Jun 12, 2014 at 5:18 PM, Brian Di Palma wrote: > On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf > wrote: > > isn't the foot gun the difference between single and multiple exports, > i.e. > > I thought it was imports that were being misused. People were writing > > module m from 'mymodule'; > > m(); > > So they treated `module` just like `import`. I'm not sure I see the > logic in doing that. > Did they not wonder why there were two ways to accomplish the exact same > thing? > As I said, I didn't find the reasoning compelling. > > > to import underscore you'd use > > > > module _ from 'underscore' > > > > because it is multiple methods on an object but for jquery you'd have to > use > > > > import $ from 'jquery' > > > > because the root object is a function instead of an object > > > > On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith > wrote: > >> > >>> > >>> I was more wondering if there was anything preventing a module import > >>> statement from being added later, if it was found to be a requirement. > >>> I can't see any reason why it couldn't, that would also allow time for > >>> bikeshedding the syntax. > >> > >> > >> It could be added later, but to turn the question around: why should it > >> be > >> dropped? It has been part of the design for a very long time, it's > >> currently used by many people working in the ES6 space, and it meets a > >> semantic need. > >> > >> If you want to drop a feature this late in the game, then you need to > show > >> that it's one of the following: > >> > >> 1. Buggy > >> 2. A footgun > >> 3. Not useful > >> 4. Future-hostile > >> > >> I don't see that it meets any of those requirements, do you? > > > > I have no strong opinions either way. I don't feel it's any of those > things. > > > > The argument that was given was that people were confused by it and > > were using it like an `import` statement. > > I said to Eric via Twitter that if people were building incorrect > > compilers and modules then they will eventually learn the error of > > their assumptions. > > > > To me the argument didn't seem that strong, the native implementations > > will be correct and people will correct their broken code. > > > > I'm not supporting the removal. I simply don't think it's a catastrophe. > > > >> > >> 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
Re: Null iterable in for-of?
On 06/12/2014 03:25 PM, Brendan Eich wrote: > Actually, if memory serves, IE JScript tolerated null and undefined on right > of for-in. SpiderMonkey and my ur-JS implementation, Mocha, did not. Someone > with the jwz nostalgia Netscape 2/3 browsers, please test. Hmm. I'm reciting tribal knowledge that I'm probably misremembering at this point, so I bet you're right. > I don't think bug-hiding precedent trumps bug-finding, personally. Allen? Agreed. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
One unusual but interesting metric: try to find blog posts explaining module m from 'mymodule'; vs posts explaining import. At least my attempts failed. Basically authors who thought ES6 modules are worth explaining did not think 'module' was worth explaining. jjb On Thu, Jun 12, 2014 at 2:18 PM, Brian Di Palma wrote: > On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf > wrote: > > isn't the foot gun the difference between single and multiple exports, > i.e. > > I thought it was imports that were being misused. People were writing > > module m from 'mymodule'; > > m(); > > So they treated `module` just like `import`. I'm not sure I see the > logic in doing that. > Did they not wonder why there were two ways to accomplish the exact same > thing? > As I said, I didn't find the reasoning compelling. > > > to import underscore you'd use > > > > module _ from 'underscore' > > > > because it is multiple methods on an object but for jquery you'd have to > use > > > > import $ from 'jquery' > > > > because the root object is a function instead of an object > > > > On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith > wrote: > >> > >>> > >>> I was more wondering if there was anything preventing a module import > >>> statement from being added later, if it was found to be a requirement. > >>> I can't see any reason why it couldn't, that would also allow time for > >>> bikeshedding the syntax. > >> > >> > >> It could be added later, but to turn the question around: why should it > >> be > >> dropped? It has been part of the design for a very long time, it's > >> currently used by many people working in the ES6 space, and it meets a > >> semantic need. > >> > >> If you want to drop a feature this late in the game, then you need to > show > >> that it's one of the following: > >> > >> 1. Buggy > >> 2. A footgun > >> 3. Not useful > >> 4. Future-hostile > >> > >> I don't see that it meets any of those requirements, do you? > > > > I have no strong opinions either way. I don't feel it's any of those > things. > > > > The argument that was given was that people were confused by it and > > were using it like an `import` statement. > > I said to Eric via Twitter that if people were building incorrect > > compilers and modules then they will eventually learn the error of > > their assumptions. > > > > To me the argument didn't seem that strong, the native implementations > > will be correct and people will correct their broken code. > > > > I'm not supporting the removal. I simply don't think it's a catastrophe. > > > >> > >> 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
Re: Re: Null iterable in for-of?
throw. Fast fail is better. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
On Jun 12, 2014, at 3:18 PM, André Bargull wrote:
> Corrected link: https://bugs.ecmascript.org/show_bug.cgi?id=2737
>
>
> On 6/13/2014 12:16 AM, André Bargull wrote:
>>> On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
>>>
>>> > Somehow I missed when we decided to allow null/undefined as the iterable
>>> > value in for-of loops.
>>> >
>>> > The following test passes using the spec algorithms:
>>> >
>>> > var c = 0;
>>> > for (var x of null) {
>>> > c++;
>>> > }
>>> > assert.equal(c, 0);
>>> >
>>> > However, if we get a null value here we are most likely just masking an
>>> > user bug.
>>> >
>>> > I assume the justification is that for-in allows null here? However,
>>> > for-of is new syntax and we have the chance to get this right this time
>>> > around.
>>>
>>> Yup, there was an issue that was reported and fixed fairly recently
>>> pointing out that for-of was inconsistent with for-in in this respect.
>>
>> for-of statement iteration always ignored undefined/null (always = since it
>> was added in rev6). I've only requested in [1] to align for-of iteration in
>> statements and comprehensions to have the same behaviour w.r.t.
>> undefined/null.
>>
>>
>> [1] https://bugs.ecmascript.org/show_bug.cgi?id=273
>
Oh, right it's the comprehension consistency I was think of, so yes the
ignoring null/undefined isn't a new change.
I don't really care which way we go on this. Clean slate world I'd throw. Messy
world - coin flip.
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
Jeff Walden wrote: On 06/12/2014 03:05 PM, Allen Wirfs-Brock wrote: > I believe this behavior for for-in was added in ES5. My recollection was that Doug Crockford pushed for it. I don't recall if it was because it matched web reality or simply because he thought it was a good idea. It was added for web compatibility, to track what was originally a SpiderMonkey implementation bug, I believe. Actually, if memory serves, IE JScript tolerated null and undefined on right of for-in. SpiderMonkey and my ur-JS implementation, Mocha, did not. Someone with the jwz nostalgia Netscape 2/3 browsers, please test. I don't think bug-hiding precedent trumps bug-finding, personally. Allen? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
Corrected link: https://bugs.ecmascript.org/show_bug.cgi?id=2737
On 6/13/2014 12:16 AM, André Bargull wrote:
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
>/ Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
/>/
/>/ The following test passes using the spec algorithms:
/>/
/>/ var c = 0;
/>/ for (var x of null) {
/>/c++;
/>/ }
/>/ assert.equal(c, 0);
/>/
/>/ However, if we get a null value here we are most likely just masking an user bug.
/>/
/>/ I assume the justification is that for-in allows null here? However, for-of is new syntax and we have the chance to get this right this time around.
/
Yup, there was an issue that was reported and fixed fairly recently pointing
out that for-of was inconsistent with for-in in this respect.
for-of statement iteration always ignored undefined/null (always =
since it was added in rev6). I've only requested in [1] to align
for-of iteration in statements and comprehensions to have the same
behaviour w.r.t. undefined/null.
[1] https://bugs.ecmascript.org/show_bug.cgi?id=273
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
>/ Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
/>/
/>/ The following test passes using the spec algorithms:
/>/
/>/ var c = 0;
/>/ for (var x of null) {
/>/c++;
/>/ }
/>/ assert.equal(c, 0);
/>/
/>/ However, if we get a null value here we are most likely just masking an user bug.
/>/
/>/ I assume the justification is that for-in allows null here? However, for-of is new syntax and we have the chance to get this right this time around.
/
Yup, there was an issue that was reported and fixed fairly recently pointing
out that for-of was inconsistent with for-in in this respect.
for-of statement iteration always ignored undefined/null (always = since
it was added in rev6). I've only requested in [1] to align for-of
iteration in statements and comprehensions to have the same behaviour
w.r.t. undefined/null.
[1] https://bugs.ecmascript.org/show_bug.cgi?id=273
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
On 06/12/2014 03:05 PM, Allen Wirfs-Brock wrote: > I believe this behavior for for-in was added in ES5. My recollection was > that Doug Crockford pushed for it. I don't recall if it was because it > matched web reality or simply because he thought it was a good idea. It was added for web compatibility, to track what was originally a SpiderMonkey implementation bug, I believe. > I agree that treating null/undefined as an empty collection has a smell. > However, in this case my I agree with who ever it was who reported this. that > consistancy between for-in and for-of is what we should have for this > condition. The spec regarding for-of read the other way, before the latest update, precisely because the web compatibility argument was poor justification for for-in working that way, and for-of was an opportunity to do the right thing. (SpiderMonkey implements the throw-on-null/undefined behavior now.) This was a deliberate inconsistency. I would have argued/responded in that bug with WONTFIX. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
> Somehow I missed when we decided to allow null/undefined as the iterable
> value in for-of loops.
>
> The following test passes using the spec algorithms:
>
> var c = 0;
> for (var x of null) {
> c++;
> }
> assert.equal(c, 0);
>
> However, if we get a null value here we are most likely just masking an user
> bug.
>
> I assume the justification is that for-in allows null here? However, for-of
> is new syntax and we have the chance to get this right this time around.
Yup, there was an issue that was reported and fixed fairly recently pointing
out that for-of was inconsistent with for-in in this respect.
I agree that treating null/undefined as an empty collection has a smell.
However, in this case my I agree with who ever it was who reported this. that
consistancy between for-in and for-of is what we should have for this condition.
BTW, I believe this behavior for for-in was added in ES5. My recollection was
that Doug Crockford pushed for it. I don't recall if it was because it matched
web reality or simply because he thought it was a good idea.
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
Null iterable in for-of?
Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
The following test passes using the spec algorithms:
var c = 0;
for (var x of null) {
c++;
}
assert.equal(c, 0);
However, if we get a null value here we are most likely just masking an
user bug.
I assume the justification is that for-in allows null here? However, for-of
is new syntax and we have the chance to get this right this time around.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf wrote: > isn't the foot gun the difference between single and multiple exports, i.e. I thought it was imports that were being misused. People were writing module m from 'mymodule'; m(); So they treated `module` just like `import`. I'm not sure I see the logic in doing that. Did they not wonder why there were two ways to accomplish the exact same thing? As I said, I didn't find the reasoning compelling. > to import underscore you'd use > > module _ from 'underscore' > > because it is multiple methods on an object but for jquery you'd have to use > > import $ from 'jquery' > > because the root object is a function instead of an object > > On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith wrote: >> >>> >>> I was more wondering if there was anything preventing a module import >>> statement from being added later, if it was found to be a requirement. >>> I can't see any reason why it couldn't, that would also allow time for >>> bikeshedding the syntax. >> >> >> It could be added later, but to turn the question around: why should it >> be >> dropped? It has been part of the design for a very long time, it's >> currently used by many people working in the ES6 space, and it meets a >> semantic need. >> >> If you want to drop a feature this late in the game, then you need to show >> that it's one of the following: >> >> 1. Buggy >> 2. A footgun >> 3. Not useful >> 4. Future-hostile >> >> I don't see that it meets any of those requirements, do you? > > I have no strong opinions either way. I don't feel it's any of those things. > > The argument that was given was that people were confused by it and > were using it like an `import` statement. > I said to Eric via Twitter that if people were building incorrect > compilers and modules then they will eventually learn the error of > their assumptions. > > To me the argument didn't seem that strong, the native implementations > will be correct and people will correct their broken code. > > I'm not supporting the removal. I simply don't think it's a catastrophe. > >> >> 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
Re: Re: Rationale for dropping ModuleImport syntax?
isn't the foot gun the difference between single and multiple exports, i.e. to import underscore you'd use module _ from 'underscore' because it is multiple methods on an object but for jquery you'd have to use import $ from 'jquery' because the root object is a function instead of an object On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith wrote: > >> >> I was more wondering if there was anything preventing a module import >> statement from being added later, if it was found to be a requirement. >> I can't see any reason why it couldn't, that would also allow time for >> bikeshedding the syntax. > > > It could be added later, but to turn the question around: why should it be > dropped? It has been part of the design for a very long time, it's > currently used by many people working in the ES6 space, and it meets a > semantic need. > > If you want to drop a feature this late in the game, then you need to show > that it's one of the following: > > 1. Buggy > 2. A footgun > 3. Not useful > 4. Future-hostile > > I don't see that it meets any of those requirements, do you? I have no strong opinions either way. I don't feel it's any of those things. The argument that was given was that people were confused by it and were using it like an `import` statement. I said to Eric via Twitter that if people were building incorrect compilers and modules then they will eventually learn the error of their assumptions. To me the argument didn't seem that strong, the native implementations will be correct and people will correct their broken code. I'm not supporting the removal. I simply don't think it's a catastrophe. > > 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
Re: IsConstructor
On Thu, Jun 12, 2014 at 3:21 PM, Allen Wirfs-Brock wrote: > It's not obvious to me why we would need @@new in addition to @@create (which > is pretty much equivalent to saying it's not clear to me why we need > [[Construct]]). For the ordinary case, @@new would just be another level of > method lookup and invocation that would be required on each new. While we > expect implementations to (eventually) optimize all of this, we still tried > to minimize the amount of boiler plate work required for each new. >From my perspective, it's about simplifying the language. I like the fact that 'new C' is "just" sugar for an ordinary method invocation on C. It would simplify the presentation of the spec as well: various places that currently state special behavior for "new XYZ" forms could instead describe the ordinary method XYZ.@@new. And as Jason points out, this conceptual simplification of the language translates into concrete API simplifications for reflective operations like Proxies. I don't think there are any special security issues involved, since I can already do: `let x = Reflect.construct.bind(Reflect, C)` and pass that around. --scott (fwiw, Crockford's "Simplified JavaScript" in http://javascript.crockford.com/tdop/tdop.html and my own "TurtleScript" subset of JavaScript in https://github.com/cscott/TurtleScript both did away with the new operator. TurtleScript replaced it with `Function#New`.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller wrote: > I like this list. I prefer #c. > * We have previously succeeded at making previously non-generic methods > generic. I think we could get away with #c. > * It is easier for a normal JS programmer to do the equivalent of #c for > most of their classes. FWIW, if a change to the spec is needed, I also favor (c). Both generic options (b) and (c) have consistent behavior that can extend to `#valueOf`. In option (b) you would presumably invoke `Object#valueOf` and for option (c) you'd return the "zero" value. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith wrote: > >> >> I was more wondering if there was anything preventing a module import >> statement from being added later, if it was found to be a requirement. >> I can't see any reason why it couldn't, that would also allow time for >> bikeshedding the syntax. > > > It could be added later, but to turn the question around: why should it be > dropped? It has been part of the design for a very long time, it's > currently used by many people working in the ES6 space, and it meets a > semantic need. > > If you want to drop a feature this late in the game, then you need to show > that it's one of the following: > > 1. Buggy > 2. A footgun > 3. Not useful > 4. Future-hostile > > I don't see that it meets any of those requirements, do you? I have no strong opinions either way. I don't feel it's any of those things. The argument that was given was that people were confused by it and were using it like an `import` statement. I said to Eric via Twitter that if people were building incorrect compilers and modules then they will eventually learn the error of their assumptions. To me the argument didn't seem that strong, the native implementations will be correct and people will correct their broken code. I'm not supporting the removal. I simply don't think it's a catastrophe. > > Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Re: Rationale for dropping ModuleImport syntax?
That's a very good set of criteria, Kevin; I think it helps frame the discussion. I think the argument is that, based on experience with the transpilers, it is a footgun, with related to people not knowing when to use which. This has been exacerbated by transpilers not correctly distinguishing `import x from "y"` and `module x from "y"`, and the complete lack of stable usable documentation for the spec. In my opinion, people have not had enough experience with a documented, stable, spec, or with non-buggy transpilers, so trying to argue that it is a footgun in the current environment should not hold much weight. There are also arguments that it is not useful, but I think those arguments are specious for the reasons I've already been over earlier. From: es-discuss on behalf of Kevin Smith Sent: Thursday, June 12, 2014 15:50 To: Brian Di Palma Cc: es-discuss list Subject: Re: Re: Rationale for dropping ModuleImport syntax? I was more wondering if there was anything preventing a module import statement from being added later, if it was found to be a requirement. I can't see any reason why it couldn't, that would also allow time for bikeshedding the syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
I like this list. I prefer #c.
* We have previously succeeded at making previously non-generic methods
generic. I think we could get away with #c.
* It is easier for a normal JS programmer to do the equivalent of #c for
most of their classes.
* Doesn't requiring branding the builtin prototypes unnecessarily.
* Works fine across Realms.
On Thu, Jun 12, 2014 at 11:29 AM, C. Scott Ananian
wrote:
> On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock
> wrote:
> > So, I think the current spec. best matches our consensus about changing
> > these prototypes to non-consructor instances. I think my proposed
> > alternative toString fall back pattern is more useful, but is a bigger
> > breaking change. Are we willing to up the bet, or should we let it ride
> as
> > is?
>
> Just restating and naming the alternatives:
>
> (a) `#toString` throws TypeError when given a non-instance. Changes
> `Date#toString()`, no change to `Date#toString.call({})`.
>
> (b) `#toString` is generic; invokes `Object#toString` when given a
> non-instance. Changes both `Date#toString()` and
> `Date#toString.call({})`.
>
> (c) `#toString` is generic; uses a "zero" value when given a
> non-instance. No change to `Date#toString()`; changes
> `Date#toString.call({})`.
>
> (d) `#toString` returns a "zero" value when given a prototype, throws
> TypeError otherwise. No change to `Date#toString()` or
> `Date#toString.call({})`.
>
> Option (a) is what is in the current spec.
> Options (b) and (c) make the `toString` method generic.
> Option (d) preserves compatibility to the greatest degree possible.
> --scott
>
> ps. I prefer (a).
> ___
> 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: Re: Rationale for dropping ModuleImport syntax?
> > I was more wondering if there was anything preventing a module import > statement from being added later, if it was found to be a requirement. > I can't see any reason why it couldn't, that would also allow time for > bikeshedding the syntax. > It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
In ES6, do for loops with a let/const initializer create a separate scope?
In other words, is
for (let i = 0; i < 10; i++) {
let i;
}
legal? I feel it is, but I'm not sure if the specs has made that clear.
Thanks!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On 6/12/14, 3:38 PM, Allen Wirfs-Brock wrote: Is the custom [[Call]] only use to implement WebIDL overload/argument processing semantics? Or do you perform object allocations within the [[Call]. Right now the [[Call]] allocates a new object of the right sort. Have you looked at how such constructors would behave when a subclass constructor does a super call to them? We need to figure out how to support subclassing, yes. The current setup does not. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Jun 12, 2014, at 12:25 PM, Boris Zbarsky wrote: > On 6/12/14, 3:21 PM, Allen Wirfs-Brock wrote: >> simply not knowing whether all of the DOM [[Construct]] semantics could be >> successfully replaced replaced using only @@create methods and constructor >> bodies. > > WebIDL currently doesn't use a custom [[Construct]] at all. It uses a custom > [[Call]] on DOM constructors. Is the custom [[Call]] only use to implement WebIDL overload/argument processing semantics? Or do you perform object allocations within the [[Call]. Have you looked at how such constructors would behave when a subclass constructor does a super call to them? > > Chances are, we want to move from that to using @@create or whatever is > needed to allow subclassing. In either case, I don't think we'll be doing > custom [[Construct]] in the DOM. When we talked about this in TC29 I don't think anybody identified any specific cases where they knew it would be an issue. The hesitation was more about uncertainty concern the unknown. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 9:30 PM, Allen Wirfs-Brock
wrote:
>
> On Jun 12, 2014, at 12:14 PM, C. Scott Ananian wrote:
>
> > On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
> > wrote:
> >> On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian <
> ecmascr...@cscott.net>
> >> wrote:
> >>> (a) `#toString` throws TypeError when given a non-instance. Changes
> >>> `Date#toString()`, no change to `Date#toString.call({})`.
> >>>
> >>> (b) `#toString` is generic; invokes `Object#toString` when given a
> >>> non-instance. Changes both `Date#toString()` and
> >>> `Date#toString.call({})`.
> >>>
> >>> (c) `#toString` is generic; uses a "zero" value when given a
> >>> non-instance. No change to `Date#toString()`; changes
> >>> `Date#toString.call({})`.
> >>>
> >>> (d) `#toString` returns a "zero" value when given a prototype, throws
> >>> TypeError otherwise. No change to `Date#toString()` or
> >>> `Date#toString.call({})`.
> >>
> >> There is (e) `#toString` returns "[object Object]" when invoked on the
> (an)
> >> original Date.prototype (regardless of the Realm it came from).
> Otherwise,
> >> it throws when invoked on a non-instance.
> >>
> >> This is what Allen and me proposed.
> >
> > Allen said:
> >> Your proposed change would return ToDateString(NaN) for both cases. So
> that preserves the ES5 level result when applied to Date.prototype but
> changes the result for any other non-Date object.
> >>
> >> With my proposed solution they would both produce "[object Object]"
> for both cases. So it changes the result of both cases, relative to ES5.
> >
> > ...which is option (b). (Allen, correct me if I'm reading that wrong!)
>
Oh, sorry, I missed that.
>
> you're right.
>
> Till, In the spec. we don't actually have a good way to identify any
> Date.prototype object from any Realm. We'd have to brand all Date.prototype
> objects in some way. It could be done, but it isn't something I would
> expect anybody to every bother to do for user defined classes. If such
> cross realm detection is actually important for Date why isn't it also
> important for the classes that a JS programmer defines.
>
Fair. (Ignoring the fact that all actual implementations probably do have a
way to do this.) What about only special-casing Date.prototype from the
current Realm, then? We have %DatePrototype% for that, and it probably
covers the vast majority of the compatibility concerns.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Jun 12, 2014, at 12:14 PM, C. Scott Ananian wrote:
> On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
> wrote:
>> On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian
>> wrote:
>>> (a) `#toString` throws TypeError when given a non-instance. Changes
>>> `Date#toString()`, no change to `Date#toString.call({})`.
>>>
>>> (b) `#toString` is generic; invokes `Object#toString` when given a
>>> non-instance. Changes both `Date#toString()` and
>>> `Date#toString.call({})`.
>>>
>>> (c) `#toString` is generic; uses a "zero" value when given a
>>> non-instance. No change to `Date#toString()`; changes
>>> `Date#toString.call({})`.
>>>
>>> (d) `#toString` returns a "zero" value when given a prototype, throws
>>> TypeError otherwise. No change to `Date#toString()` or
>>> `Date#toString.call({})`.
>>
>> There is (e) `#toString` returns "[object Object]" when invoked on the (an)
>> original Date.prototype (regardless of the Realm it came from). Otherwise,
>> it throws when invoked on a non-instance.
>>
>> This is what Allen and me proposed.
>
> Allen said:
>> Your proposed change would return ToDateString(NaN) for both cases. So that
>> preserves the ES5 level result when applied to Date.prototype but changes
>> the result for any other non-Date object.
>>
>> With my proposed solution they would both produce "[object Object]" for
>> both cases. So it changes the result of both cases, relative to ES5.
>
> ...which is option (b). (Allen, correct me if I'm reading that wrong!)
you're right.
Till, In the spec. we don't actually have a good way to identify any
Date.prototype object from any Realm. We'd have to brand all Date.prototype
objects in some way. It could be done, but it isn't something I would expect
anybody to every bother to do for user defined classes. If such cross realm
detection is actually important for Date why isn't it also important for the
classes that a JS programmer defines.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On 6/12/14, 3:21 PM, Allen Wirfs-Brock wrote: simply not knowing whether all of the DOM [[Construct]] semantics could be successfully replaced replaced using only @@create methods and constructor bodies. WebIDL currently doesn't use a custom [[Construct]] at all. It uses a custom [[Call]] on DOM constructors. Chances are, we want to move from that to using @@create or whatever is needed to allow subclassing. In either case, I don't think we'll be doing custom [[Construct]] in the DOM. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Jun 12, 2014, at 11:30 AM, Jason Orendorff wrote: > On Thu, Jun 12, 2014 at 10:06 AM, Domenic Denicola > wrote: >> I'd be most interested in seeing if we can remove IsConstructor entirely >> (except for uses where it's just a guard, implementing the semantics of >> `new` via IsConstructor -> [[Construct]] or throw). >> >> It seems like there's at least some movement toward removing it from >> `Array.of` and `Array.from`. All that remains is its use to preserve the >> `arrayInstance.constructor = undefined` backward-compatibility possibilities. > > Proxies also observe it. > > I *really* wish we just had an @@new for this, such that >new C(...args) > is just shorthand for > C[Symbol.new](...args) > and the construct trap could be removed from proxies altogether. :-| At TC39 meetings (and probably on some es-discuss threads) we've talked about eliminating [[Construct]] and simply inlining its ordinary definition (more or less: C.apply(C[Symbol.create](), args) ). We didn't reach consensus to do so. I believe that some of the concern was simply not knowing whether all of the DOM [[Construct]] semantics could be successfully replaced replaced using only @@create methods and constructor bodies. Another possible concern is an exotic [[Construct]] can't be invoked any way other than using the new operator. A @@create (or a hypothetical @@new) can be copied around and invoked from arbitrary places. This raises concerns about whether their might be security exploits that could be built upon them. It's not obvious to me why we would need @@new in addition to @@create (which is pretty much equivalent to saying it's not clear to me why we need [[Construct]]). For the ordinary case, @@new would just be another level of method lookup and invocation that would be required on each new. While we expect implementations to (eventually) optimize all of this, we still tried to minimize the amount of boiler plate work required for each new. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
wrote:
> On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian
> wrote:
>> (a) `#toString` throws TypeError when given a non-instance. Changes
>> `Date#toString()`, no change to `Date#toString.call({})`.
>>
>> (b) `#toString` is generic; invokes `Object#toString` when given a
>> non-instance. Changes both `Date#toString()` and
>> `Date#toString.call({})`.
>>
>> (c) `#toString` is generic; uses a "zero" value when given a
>> non-instance. No change to `Date#toString()`; changes
>> `Date#toString.call({})`.
>>
>> (d) `#toString` returns a "zero" value when given a prototype, throws
>> TypeError otherwise. No change to `Date#toString()` or
>> `Date#toString.call({})`.
>
> There is (e) `#toString` returns "[object Object]" when invoked on the (an)
> original Date.prototype (regardless of the Realm it came from). Otherwise,
> it throws when invoked on a non-instance.
>
> This is what Allen and me proposed.
Allen said:
> Your proposed change would return ToDateString(NaN) for both cases. So that
> preserves the ES5 level result when applied to Date.prototype but changes the
> result for any other non-Date object.
>
> With my proposed solution they would both produce "[object Object]" for both
> cases. So it changes the result of both cases, relative to ES5.
...which is option (b). (Allen, correct me if I'm reading that wrong!)
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian
wrote:
> On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock
> wrote:
> > So, I think the current spec. best matches our consensus about changing
> > these prototypes to non-consructor instances. I think my proposed
> > alternative toString fall back pattern is more useful, but is a bigger
> > breaking change. Are we willing to up the bet, or should we let it ride
> as
> > is?
>
> Just restating and naming the alternatives:
>
> (a) `#toString` throws TypeError when given a non-instance. Changes
> `Date#toString()`, no change to `Date#toString.call({})`.
>
> (b) `#toString` is generic; invokes `Object#toString` when given a
> non-instance. Changes both `Date#toString()` and
> `Date#toString.call({})`.
>
> (c) `#toString` is generic; uses a "zero" value when given a
> non-instance. No change to `Date#toString()`; changes
> `Date#toString.call({})`.
>
> (d) `#toString` returns a "zero" value when given a prototype, throws
> TypeError otherwise. No change to `Date#toString()` or
> `Date#toString.call({})`.
>
> Option (a) is what is in the current spec.
> Options (b) and (c) make the `toString` method generic.
> Option (d) preserves compatibility to the greatest degree possible.
>
There is (e) `#toString` returns "[object Object]" when invoked on the (an)
original Date.prototype (regardless of the Realm it came from). Otherwise,
it throws when invoked on a non-instance.
This is what Allen and me proposed. And I think it's the best solution for
two reasons:
- I'd bet good money that (a) breaks the web so just isn't an option.
- as Jason points out, stringifying an object should succeed for as many
things as possible. The script authors can do what they want, but the
builtins shouldn't throw if you stringify them.
As André points out, this affects `valueOf`, too.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Thu, Jun 12, 2014 at 2:30 PM, Jason Orendorff wrote: > I *really* wish we just had an @@new for this, such that > new C(...args) > is just shorthand for >C[Symbol.new](...args) > and the construct trap could be removed from proxies altogether. :-| +1. `Function.@@new` could be added to ES7, but the ugly construct trap will be with us forever. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Thu, Jun 12, 2014 at 1:30 PM, Jason Orendorff wrote: > I *really* wish we just had an @@new for this, such that > new C(...args) > is just shorthand for >C[Symbol.new](...args) > and the construct trap could be removed from proxies altogether. :-| I forgot to add: then the rare code that really wants to ask "is x a constructor?" can say if (x[Symbol.new] !== undefined) ... like Array.from does for @@iterator. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Thu, Jun 12, 2014 at 10:06 AM, Domenic Denicola wrote: > I'd be most interested in seeing if we can remove IsConstructor entirely > (except for uses where it's just a guard, implementing the semantics of `new` > via IsConstructor -> [[Construct]] or throw). > > It seems like there's at least some movement toward removing it from > `Array.of` and `Array.from`. All that remains is its use to preserve the > `arrayInstance.constructor = undefined` backward-compatibility possibilities. Proxies also observe it. I *really* wish we just had an @@new for this, such that new C(...args) is just shorthand for C[Symbol.new](...args) and the construct trap could be removed from proxies altogether. :-| -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock
wrote:
> So, I think the current spec. best matches our consensus about changing
> these prototypes to non-consructor instances. I think my proposed
> alternative toString fall back pattern is more useful, but is a bigger
> breaking change. Are we willing to up the bet, or should we let it ride as
> is?
Just restating and naming the alternatives:
(a) `#toString` throws TypeError when given a non-instance. Changes
`Date#toString()`, no change to `Date#toString.call({})`.
(b) `#toString` is generic; invokes `Object#toString` when given a
non-instance. Changes both `Date#toString()` and
`Date#toString.call({})`.
(c) `#toString` is generic; uses a "zero" value when given a
non-instance. No change to `Date#toString()`; changes
`Date#toString.call({})`.
(d) `#toString` returns a "zero" value when given a prototype, throws
TypeError otherwise. No change to `Date#toString()` or
`Date#toString.call({})`.
Option (a) is what is in the current spec.
Options (b) and (c) make the `toString` method generic.
Option (d) preserves compatibility to the greatest degree possible.
--scott
ps. I prefer (a).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 6:37 PM, Chris Toshok wrote:
> On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma wrote:
>>
>> Is there anything preventing the addition of a "ModuleImport" like
>> affordance at a later stage (e.g. ES7)?
>
>
> ModuleImport is the only way (in syntax) to achieve CommonJS `require`
> behavior on the consumer-side when a module author exclusively uses multiple
> exports.
>
> Its lack will force existing module maintainers to export as small a set as
> possible - likely either a single identifier - so that they can service the
> existing identifier-as-namespace convention CommonJS forces.
>
> Given that there's no real syntactic difference between single identifier
> export and default export, I would imagine default export would win since
> then you get: `import _ from 'underscore'` instead of import { _ } from
> 'underscore'`.
>
I can see that being a valid path for certain modules to take. I'm not
sure large utility packages will be as prevelant in future though.
Once we have a standard module system it seems just as likely that
these packages might break apart somewhat.
There seems no reason to load all of underscore into a module for just
one or two functions.
The underscore web page itself divides the functions http://underscorejs.org/
We should also be wary of building cases on code from Parsers, I
believe the unstructured switch statement was designed for parsers.
It didn't turn out to be an optimal design for routine programming though.
I was more wondering if there was anything preventing a module import
statement from being added later, if it was found to be a requirement.
I can't see any reason why it couldn't, that would also allow time for
bikeshedding the syntax.
>> Related to some other comments made in this thread, I think static
>> verification errors are a great idea.
>> I'd also like to echo the comments that ES6 modules seem well
>> designed, looking forward to native implementations.
>
>
> I definitely agree. I think the semantics and specification are awesome.
> And having syntax at all is *huge* for tooling and aot/static compilers.
>
> The ModuleImport syntax can be bikeshedded until the cows come home. It's
> not important (to me). What's important is that there is syntax to get at
> its functionality, not imperative code.
>
The imperative code given as an alternative is ugly, it probably won't
gain many users.
> IMO the only real issue is the tight coupling between syntax used to import
> and syntax used to export. Why as a module consumer should the module
> author's choice dictate which syntax I'm forced to use? And why as a module
> author should the syntax my users want to use dictate how I have to export
> my module? If syntaxes were decoupled, ModuleImport could go away and we
> wouldn't lose the functionality, it would simply be `import _ from
> 'underscore'`.
I like the idea but I can't imagine many people would welcome yet more
changes to ES modules.
>
> I don't think it's outlandish, the possibility that a large enough portion
> of the community will decide on a single import syntax as "best", and
> network effects will result in it going from "best" to "only".
>
> -c
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma wrote:
> Is there anything preventing the addition of a "ModuleImport" like
> affordance at a later stage (e.g. ES7)?
>
ModuleImport is the only way (in syntax) to achieve CommonJS `require`
behavior on the consumer-side when a module author exclusively uses
multiple exports.
Its lack will force existing module maintainers to export as small a set as
possible - likely either a single identifier - so that they can service the
existing identifier-as-namespace convention CommonJS forces.
Given that there's no real syntactic difference between single identifier
export and default export, I would imagine default export would win since
then you get: `import _ from 'underscore'` instead of import { _ } from
'underscore'`.
Related to some other comments made in this thread, I think static
> verification errors are a great idea.
> I'd also like to echo the comments that ES6 modules seem well
> designed, looking forward to native implementations.
I definitely agree. I think the semantics and specification are awesome.
And having syntax at all is *huge* for tooling and aot/static compilers.
The ModuleImport syntax can be bikeshedded until the cows come home. It's
not important (to me). What's important is that there is syntax to get at
its functionality, not imperative code.
IMO the only real issue is the tight coupling between syntax used to import
and syntax used to export. Why as a module consumer should the module
author's choice dictate which syntax I'm forced to use? And why as a
module author should the syntax my users want to use dictate how I have to
export my module? If syntaxes were decoupled, ModuleImport could go away
and we wouldn't lose the functionality, it would simply be `import _ from
'underscore'`.
I don't think it's outlandish, the possibility that a large enough portion
of the community will decide on a single import syntax as "best", and
network effects will result in it going from "best" to "only".
-c
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 12:48 PM, Jason Orendorff https://mail.mozilla.org/listinfo/es-discuss>> wrote: >/ In any case, I doubt we have a choice. ES3-5 at least supported it. There is />/ surely a Web page somewhere that calls .toString() on every object it can />/ find, just because. / Or a web page converts some value to a string using `"" + someValue`, in which case adding a toString() legacy mode is not sufficient, because valueOf() is actually invoked (well, except for Date.prototype because of its @@toPrimitive override). Does that mean valueOf() also needs to have a legacy mode to special case the prototype object? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Jun 12, 2014, at 8:57 AM, Erik Arvidsson wrote:
> On Thu Jun 12 2014 at 11:28:12 AM, C. Scott Ananian
> wrote:
> It would be slightly more "JavaScripty" to have
> Date.prototype.[[DateValue]] exist, and be set to the epoch or some
> such.
>
> +1
>
> 1. Let date be the this value.
> 2. If Type(date) is not Object then, throw a TypeError exception.
> 3. If date does not have a [[DateValue]] internal slot, then let tv be NaN
> 4. Else let tv be this time value.
> 5. Return ToDateString(tv).
>
> Allen, what is the benefit to do `super.toString()` instead?
This is really getting into how much and where we want to break legacy
compatibility.
ES5 actually under specifies Data.prototype.toString. It doesn't say what then
the this value is not a Date instance. Actually it says that the result is
implementation dependent.
But, let's assume that it was in fact specified more like the current ES6 spec
which your above proposed change is derived from. The same reasoning can be
applicable to the Number, String, etc. which happen to be more precisely
specified in ES5.
In that case, in ES5 (where Date.prototype is a Date instance)
Date.prototyjpe.toString()
should produce ToDateString(NaN), and
Date.prototype.toString.call({ });
should throw because 'date' does not have a [[DateValue]] internal slot.
Your proposed change would return ToDateString(NaN) for both cases. So that
preserves the ES5 level result when applied to Date.prototype but changes the
result for any other non-Date object.
With my proposed solution they would both produce "[object Object]" for both
cases. So it changes the result of both cases, relative to ES5.
So both solutions change the result produce for non-Date objects. I also change
the results for Date.prototype while your solution preserves it. Which
breaking change are we willing to to risk? In making the change to
non-instance prototypes we placed a bet that nobody depended upon those
prototypes being instances of their constructor. That presumably means that we
were also betting that nobody is dependent upon the result you get when
applying toString to those prototypes. From that perspective, the current
spec. language is a good match to our bet. It changes what happens for
toString applied to the prototype, but it preserves other Date toString
behavior including throwing when Date.prototype.toString is applied to a
non-Date object.
So, I think the current spec. best matches our consensus about changing these
prototypes to non-consructor instances. I think my proposed alternative
toString fall back pattern is more useful, but is a bigger breaking change. Are
we willing to up the bet, or should we let it ride as is?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 12:48 PM, Jason Orendorff wrote: > In any case, I doubt we have a choice. ES3-5 at least supported it. There is > surely a Web page somewhere that calls .toString() on every object it can > find, just because. If you are concerned about compatibility, them `Date.prototype.toString()` should return "Invalid Date" (as Erik stated, in concrete pseudo-code, above), not the result of `Object.prototype.toString()`. Similarly, `Boolean.prototype.toString()` should return `false`, etc. If we're changing the result of `#toString`, then we should just throw a `TypeError`, rather than return some arbitrary value. Specifically, I want `Date#toString` to consistently throw a `TypeError` if `this` is not a `Date` (or subclass), not to do some weird special case only for `Date.prototype`. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 6:03 PM, C. Scott Ananian
wrote:
> FWIW, in Chrome 36:
>
> ```javascript
> > Date.prototype.toString()
> "Invalid Date"
> > ({ toString: Date.prototype.toString }).toString()
> TypeError: this is not a Date object.
> > Number.prototype.toString()
> "0"
> > String.prototype.toString()
> ""
> > Boolean.prototype.toString()
> "false"
> > RegExp.prototype.toString()
> "/(?:)/"
> ```
>
Yes, that's how it's supposed to work according to ES5, and does in all
engines. Annex E.1 of ES6 notes that this changes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
If Date.prototype is a Date, then we need additional special logic to ensure that freezing it actually makes it immutable. Otherwise, we have a hard to plug global communications channel. This was the reason why RegExp.prototype.compile had an [[Extensible]] check, and why we can remove the check if RegExp.prototype is no longer a RegExp. On Thu, Jun 12, 2014 at 8:57 AM, Erik Arvidsson wrote: > On Thu Jun 12 2014 at 11:28:12 AM, C. Scott Ananian > wrote: > >> It would be slightly more "JavaScripty" to have >> Date.prototype.[[DateValue]] exist, and be set to the epoch or some >> such. >> > > +1 > > 1. Let date be the this value. > 2. If Type(date) is not Object then, throw a TypeError exception. > 3. If date does not have a [[DateValue]] internal slot, then let tv be NaN > 4. Else let tv be this time value. > 5. Return ToDateString(tv). > > Allen, what is the benefit to do `super.toString()` instead? > > > >> >> This problem actually seems to be an artifact of the way that >> [[Construct]] works in ES6 -- but the takeaway is that prototypes of a >> class are not themselves instances of the class. It's not surprising >> that methods of the class thus don't work on the prototype. I'd vote >> WONTFIX. >> --scott >> ___ >> 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: Standard builtins' prototypes and toString
FWIW, in Chrome 36:
```javascript
> Date.prototype.toString()
"Invalid Date"
> ({ toString: Date.prototype.toString }).toString()
TypeError: this is not a Date object.
> Number.prototype.toString()
"0"
> String.prototype.toString()
""
> Boolean.prototype.toString()
"false"
> RegExp.prototype.toString()
"/(?:)/"
```
That last one is a bit unusual.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 5:55 PM, Boris Zbarsky wrote: > On 6/12/14, 11:45 AM, André Bargull wrote: > >> And Number.prototype, String.prototype, Boolean.prototype >> > > All of those have the relevant internal fields, so they don't have the > problem. > > e.g. Number.prototype.toString() returns "0". > They won't have those fields much longer if the changes in annex E.1[1] work out. [1]: Search for "Date" in http://people.mozilla.org/~jorendorff/es6-draft.html#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions-in-the-6th-edition ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Jun 12, 2014, at 8:45 AM, André Bargull wrote: >> On Jun 12, 2014, at 5:26 AM, Till Schneidereit wrote: >> >> > While working on changing Date.prototype to be a plain object in >> > SpiderMonkey, we realized that there's an issue: the way things are >> > specced now, `alert(Date.prototype)` will throw, because >> > `Date.prototype.toString` isn't generic. The same applies for all builtins >> > with non-generic `toString` prototype functions. >> >> Fortunately there aren't very many of those. I think it is only Date and >> RegExp that have this issue among the ES6 built-ins > > And Number.prototype, String.prototype, Boolean.prototype and > Symbol.prototype. And actually it's even worse for Symbol.prototype because > of the @@toPrimitive override. Right, I left those out because I thought we didn't have an issue with them, but you're right. I'll fix them too. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Thu Jun 12 2014 at 11:28:12 AM, C. Scott Ananian wrote: > It would be slightly more "JavaScripty" to have > Date.prototype.[[DateValue]] exist, and be set to the epoch or some > such. > +1 1. Let date be the this value. 2. If Type(date) is not Object then, throw a TypeError exception. 3. If date does not have a [[DateValue]] internal slot, then let tv be NaN 4. Else let tv be this time value. 5. Return ToDateString(tv). Allen, what is the benefit to do `super.toString()` instead? > > This problem actually seems to be an artifact of the way that > [[Construct]] works in ES6 -- but the takeaway is that prototypes of a > class are not themselves instances of the class. It's not surprising > that methods of the class thus don't work on the prototype. I'd vote > WONTFIX. > --scott > ___ > 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: Standard builtins' prototypes and toString
On Thu, Jun 12, 2014 at 11:42 AM, Allen Wirfs-Brock wrote: > TC39 explicitly agreed that we would move away from the "a prototype is an > instance of its constructor" model, except where there was known legacy usage > that we had to support. That previous model make it very difficult to > generalize the initialization of prototype objects created via class > declarations. Right, which is why I'm saying I don't understand the problem with `Date.prototype.toString()`. It's not a `Date`, it's a `Date.prototype`. Throwing an error is more informative than hiding it and returning something arbitrary. As has been mentioned, debuggers have to deal with the fact that `toString` can have side-effects, throw exceptions, etc, anyway. What problem are we actually solving here? --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On 6/12/14, 11:45 AM, André Bargull wrote: And Number.prototype, String.prototype, Boolean.prototype All of those have the relevant internal fields, so they don't have the problem. e.g. Number.prototype.toString() returns "0". and Symbol.prototype. This one has the issue, though. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Jun 12, 2014, at 8:33 AM, André Bargull wrote: >> I'd be most interested in seeing if we can remove IsConstructor entirely >> (except for uses where it's just a guard, implementing the semantics of >> `new` via IsConstructor -> [[Construct]] or throw). >> >> It seems like there's at least some movement toward removing it from >> `Array.of` and `Array.from`. All that remains is its use to preserve the >> `arrayInstance.constructor = undefined` backward-compatibility >> possibilities. My preference would be to see if we can get away with >> breaking that use case, and reintroduce it if that turns out not to be >> web-compatible. > > The [[Realm]] check in Array.prototype.* is even more annoying than the > IsConstructor guard, but unfortunately required for web-compatibility per > [1]. :-( > > [1] http://esdiscuss.org/topic/array-prototype-slice-web-compat-issue Yes! Please don't rock the boat with regard to this stuff. It's all there to address real compatibility issues. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Jun 12, 2014, at 5:26 AM, Till Schneidereit wrote: >/ While working on changing Date.prototype to be a plain object in SpiderMonkey, we realized that there's an issue: the way things are specced now, `alert(Date.prototype)` will throw, because `Date.prototype.toString` isn't generic. The same applies for all builtins with non-generic `toString` prototype functions. / Fortunately there aren't very many of those. I think it is only Date and RegExp that have this issue among the ES6 built-ins And Number.prototype, String.prototype, Boolean.prototype and Symbol.prototype. And actually it's even worse for Symbol.prototype because of the @@toPrimitive override. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Jun 12, 2014, at 8:28 AM, C. Scott Ananian wrote: > It would be slightly more "JavaScripty" to have > Date.prototype.[[DateValue]] exist, and be set to the epoch or some > such. > > This problem actually seems to be an artifact of the way that > [[Construct]] works in ES6 -- but the takeaway is that prototypes of a > class are not themselves instances of the class. It's not surprising > that methods of the class thus don't work on the prototype. I'd vote > WONTFIX. > --scott TC39 explicitly agreed that we would move away from the "a prototype is an instance of its constructor" model, except where there was known legacy usage that we had to support. That previous model make it very difficult to generalize the initialization of prototype objects created via class declarations. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Thu Jun 12 2014 at 11:38:22 AM, Allen Wirfs-Brock wrote: > It when we start trying to give a function both this-dependent and > this-independent functional behavior that we get into the weeds. > Yes. Lets not do that :-) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Jun 12, 2014, at 8:30 AM, Erik Arvidsson wrote: > > Why can't we "blindly" call `this[[Construct]]`? It will throw for all of the > above cases which is pretty much what one would expect. I already said I'd be fine with that. Personally I think the practice of high-jacking methods and turning them into naked functions is something we should discourage. It when we start trying to give a function both this-dependent and this-independent functional behavior that we get into the weeds. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Jun 12, 2014, at 8:24 AM, Mark Miller wrote:
> On Thu, Jun 12, 2014 at 8:19 AM, Allen Wirfs-Brock
> wrote:
>
> Fortunately there aren't very many of those. I think it is only Date and
> RegExp that have this issue among the ES6 built-ins
>
> WeakMap, Map, Set, others?
Nope, they don't even have custom toString methods.
>
> The real problem includes ES6 classes as well. Whatever fix we choose, it
> should apply there as well -- not that I have a concrete proposal. This one's
> a real puzzler.
By default they just inherit up the prototype chain, typically to
Object.prototype.toSring
If a JS programmer chooses to over-ride toString, then it becomes their problem.
The same best practice should be taught to them too, if you are going to do a
branding check in a toString method you should fall back to the default object
behavior:
class MyClass {
toString() {
if (!myBrand(this)) return super.toString();
...
}
}
We can't do this for them because there is no universal branding concept we can
apply for them.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
I'd be most interested in seeing if we can remove IsConstructor entirely (except for uses where it's just a guard, implementing the semantics of `new` via IsConstructor -> [[Construct]] or throw). It seems like there's at least some movement toward removing it from `Array.of` and `Array.from`. All that remains is its use to preserve the `arrayInstance.constructor = undefined` backward-compatibility possibilities. My preference would be to see if we can get away with breaking that use case, and reintroduce it if that turns out not to be web-compatible. The [[Realm]] check in Array.prototype.* is even more annoying than the IsConstructor guard, but unfortunately required for web-compatibility per [1]. :-( [1] http://esdiscuss.org/topic/array-prototype-slice-web-compat-issue ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Thu Jun 12 2014 at 10:59:57 AM, Allen Wirfs-Brock
wrote:
> The problem with the undefined test is that it doesn't work if somebody
> tries to attach such functions to a namespace object:
>
It should not work. These are methods that depends on `this`.
var ns = {create: document.createElement};
ns.create('div'); // throws wrong receiver
> let arraybuilder = {of: Array.of, from: array:Array.from};
> arraybuilder.of(1,2,3,4);
>
> or consider, at the global level:
> var of = Array.of;
> of(1,2,3); //works
> this.of(1,2,3) //breaks
>
Why can't we "blindly" call `this[[Construct]]`? It will throw for all of
the above cases which is pretty much what one would expect.
That's essentially why we have the IsConstructor test. To distinguish
> between this values that are actual constructors that will be used to
> create the new collection and non-constructor objects that are just
> contains for the function.
>
> >
> > Back to the topic, it seems weird to go out of our way to expose
> > @@isRegExp and @@isConcatSpreadable and also go out of our way to hide
> > IsConstructor(). I don't like "does this object conform to this
> > protocol" tests, but they are a fact of life in real JS code.
>
> I think the @@is methods and isConstructor are different kinds of beasts.
> isConstructor wold be a very general predicate that queries a fundamental
> characteristic of the meta-object protocol. The @@is methods are local to
> the implementation of a specific abstraction and nobody really needs to
> know about them unless they are trying to extend that abstraction.
>
> I'm not really opposed to an isConstructor predicate, I'm just pushing
> back to see if it is something that really needs to be exposed. If we have
> it, I think we probably should also have a isCallable predicate and I'd
> hand both of them off of Function. IE:
>
> Functiuon.isCallable(value)
> Function.isConstructor(value) //or maybe it should be Function.isNewable ?
>
> 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
Re: 5 June 2014 TC39 Meeting Notes
On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I like , simply as a better . Whether it's worth the > cost is largely a matter of finding out what the cost is, from > implementers. I don't recall reading any opinions from them on the matter. > > > Hixie has brought up some interesting points on the interaction of >and