Le 11/06/2014 18:08, Ben Newman a écrit :
https://gist.github.com/annevk/3db3fbda2b95e5ae9427
AWB: Should we try to replace WebIDL? (fourth bullet point from the
gist above)
For what purpose? Replacing WebIDL isn't an end in itself.
Who would be the target of this replacement? Spec writers
Le 11/06/2014 18:21, Ben Newman a écrit :
## 7.1 script type=module status update (from DH)
DH: Would really rather have moduleimport { foo } from bar;
.../module, which is like script but async, strict mode, has its
own top-level scope, and can import declaratively (using ES6 module
import
Thanks for the notes, Ben! Looks like a real slog but it's much
appreciated.
On Wed 11 Jun 2014 18:28, Ben Newman benja...@cs.stanford.edu writes:
## Async Generator Functions (Jafar presenting)
(Jafar to send slides)
Looking forward to seeing these slides.
Andy
Thanks for the notes, Ben! Looks like a real slog but it's much
appreciated.
On Wed 11 Jun 2014 18:28, Ben Newman benjamin at cs.stanford.edu
https://mail.mozilla.org/listinfo/es-discuss writes:
/ ## Async Generator Functions (Jafar presenting)
// (Jafar to send slides)
/
Looking forward
Is there anything preventing the addition of a ModuleImport like
affordance at a later stage (e.g. ES7)?
I haven't done much development with ES6 modules but I've not found
much use for that form when I have.
Related to some other comments made in this thread, I think static
verification errors
On 6/12/14, 4:53 AM, David Bruant wrote:
DH: Problem: people explicitly argue against better interface design
because it's not convenient/expressible in WebIDL.
To the extent that it's the latter, we should fix WebIDL.
To the extent that it's people just being lazy, that's just not
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`
On Wed, Jun 11, 2014 at 11:44 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Array.from and Array.of have a non-throwing IsConstrutor test because they
are designed to allow things like this:
let of = Array.of;
of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5)
I don't recall why we
These are the up-to-date slides. The accompanying library is the alpha
version of the standard library I would like to see. It introduces the
Observable type, which the asynchronous generator syntax emit and consumes.
___
es-discuss mailing list
I urge TC39 to assess the cost/benefit of module carefully. It brings in
a lot of issues orthogonal to JS. script is already a mess and HTML
Imports are barely a thing. Web developers need a solution to the bundling
problem for ES modules with much, much higher priority than module.
On Thu, Jun
The slides included earlier in the thread are up-to-date. The link to the
GitHub is for the Observable type that the syntax is expected to emit and
consume.
J
Dictated using voice recognition. Please forgive the typos.
On Jun 12, 2014, at 10:02 AM, John Barton johnjbar...@google.com wrote:
I
I like module, simply as a better script. 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 module and
script in
Wow, what a mess. Let's forget the builtins for a moment and focus on JS
classes, both the old/current patterns for coding these manually, and the
new ES6 class syntax. Consider:
class Point {
constructor(x, y) {
this.x = x;
this.y = y;
},
getX() { return this.x; },
getY() {
On Jun 12, 2014, at 5:36 AM, Jason Orendorff wrote:
On Wed, Jun 11, 2014 at 11:44 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Array.from and Array.of have a non-throwing IsConstrutor test because they
are designed to allow things like this:
let of = Array.of;
of(1,2,3,4,5);
It was pointed out to me that I forgot to include the latest slides for
async generator. I was referring to the link included earlier
in the thread. Sorry for the confusion.
Here is the link again.
https://docs.google.com/a/netflix.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU
Dictated using voice
On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I like module, simply as a better script. 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.
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`.
But a module embedded in html needs script's insane parsing rules. That's why
module doesn't work and we need script type=module instead.
This isn't immediately clear to me; would you mind explaining?
I guess part of it is clarifying which part of script's insane parsing
rules we're
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
On Thu, Jun 12, 2014 at 5:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com
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,
On Thu, Jun 12, 2014 at 8:19 AM, Allen Wirfs-Brock al...@wirfs-brock.com
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,
On Jun 12, 2014, at 8: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
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
On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I like module, simply as a better script. 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.
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`.
On Jun 12, 2014, at 8:24 AM, Mark Miller wrote:
On Thu, Jun 12, 2014 at 8:19 AM, Allen Wirfs-Brock al...@wirfs-brock.com
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,
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
On Thu Jun 12 2014 at 11:38:22 AM, Allen Wirfs-Brock al...@wirfs-brock.com
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 :-)
___
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
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
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
On Thu, Jun 12, 2014 at 11:42 AM, Allen Wirfs-Brock
al...@wirfs-brock.com 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
On Thu Jun 12 2014 at 11:28:12 AM, C. Scott Ananian ecmascr...@cscott.net
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
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,
On Thu, Jun 12, 2014 at 5:55 PM, Boris Zbarsky bzbar...@mit.edu 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()
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()
/(?:)/
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
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
On Thu, Jun 12, 2014 at 6:03 PM, C. Scott Ananian ecmascr...@cscott.net
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
On Thu, Jun 12, 2014 at 12:48 PM, Jason Orendorff
jorendo...@mozilla.com 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,
On Jun 12, 2014, at 8:57 AM, Erik Arvidsson wrote:
On Thu Jun 12 2014 at 11:28:12 AM, C. Scott Ananian ecmascr...@cscott.net
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
On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma off...@gmail.com 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
On Thu, Jun 12, 2014 at 6:37 PM, Chris Toshok tos...@gmail.com wrote:
On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma off...@gmail.com 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
On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock
al...@wirfs-brock.com 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
On Thu, Jun 12, 2014 at 10:06 AM, Domenic Denicola
dome...@domenicdenicola.com 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
On Thu, Jun 12, 2014 at 1:30 PM, Jason Orendorff
jason.orendo...@gmail.com 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:
On Thu, Jun 12, 2014 at 2:30 PM, Jason Orendorff
jason.orendo...@gmail.com 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.
On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
So, I think the current spec. best matches our consensus about changing
these prototypes to non-consructor instances. I think my
On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
t...@tillschneidereit.net 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({})`.
On Jun 12, 2014, at 11:30 AM, Jason Orendorff wrote:
On Thu, Jun 12, 2014 at 10:06 AM, Domenic Denicola
dome...@domenicdenicola.com 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`
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 Jun 12, 2014, at 12:14 PM, C. Scott Ananian wrote:
On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
t...@tillschneidereit.net 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
On Thu, Jun 12, 2014 at 9:30 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 12, 2014, at 12:14 PM, C. Scott Ananian wrote:
On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
t...@tillschneidereit.net wrote:
On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian
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
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
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
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
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
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
On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith zenpars...@gmail.com 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
On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller erig...@google.com 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
On Thu, Jun 12, 2014 at 3:21 PM, Allen Wirfs-Brock
al...@wirfs-brock.com 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
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
On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf
calvin.metc...@gmail.com 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
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
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
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
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,
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
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
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
throw. Fast fail is better.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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
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
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
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 zenpars...@gmail.com wrote:
So I think this argues for two actions:
1. Leave the syntax as-is. The module from syntax makes the
On Thu, Jun 12, 2014 at 5:30 PM, Kevin Smith zenpars...@gmail.com 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
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.
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
79 matches
Mail list logo
