Re: 4 June 2014 TC39 Meeting Notes
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 (TC39 or
W3C)? authors? Implementors? All of these together?
DH: Browser implementors love WebIDL, so anything that replaces it has
to be as convenient as that. YK's idea: the new interface description
language would prepend Legacy to existing WebIDL types, but still
support them
+1.
MM: What about a design language that compiles to WebIDL?
DH: Problem: people explicitly argue against better interface design
because it's not convenient/expressible in WebIDL.
MM: Right, the path of least resistance in WebIDL is not good JavaScript.
Why? (I'm not saying I disagree, but I'm trying to understand what
WebIDL lacks)
What are people opinions on the path of least resistance in describing
interfaces in TypeScript?
DH, AR: TypeScript seemed like a way to define signatures of APIs, but
was solving a different problem.
DH: Need a way to express what kind of implicit conversions are
applied to passed-in values (something that TypeScript doesn't have).
As far as developers are concerned, it doesn't seem like an issue, so it
looks like the TypeScript interface language is sufficiently expressive
for most developer needs.
However, it looks like the notion of interface for standard features
changes whether it's taken from the point of view of an implementor or
an author.
Implementors have an imperative of interoperability with legacy APIs
which is a constraint authors don't have.
YK: Also want to be able to express APIs in terms of function/method
overloading (different behaviors for different input types), which is
more like TypeScript than WebIDL.
AWB: If no work happens to build a better IDL, we'll be stuck with the
status quo.
YK: Want to be able to describe `PromiseT` result types as such,
rather than `{ then: ???, catch: ??? }`
I want to agree, but IIRC thenables are considered like promises by
built-in algorithms, so apparently, the consensus is not that people
want a `PromiseT` type as such separate from {then, catch?}.
SK: Willing to start working on a new IDL design, with help.
DH: Want to capture duality between Array.isArray arrays and
array-like objects, and instanceof-Promise objects vs. { then:
Function } objects.
SK: Can we improve whatever was lacking about TypeScript?
An annotation system like there is now in WebIDL might be enough an
addition to express legacy behaviors.
AR, YK: TypeScript types don't mean quite what you think they mean
(Number, String).
A new interface language could keep the TypeScript syntax and adapt the
semantics as felt appropriate.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
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 syntax) from other (named) modules.
Just to be sure I understand, with module (or script type=module),
the module has to be named? So module never really makes sense on its
own and should always have a name attribute?
DH: module name=qux creates race conditions with HTML imports
(part of WebComponents).
YK: People who saw named HTML module tags though you should mix html
imports w named module imports
YK: When you have packaging solution (SPDY, etc), you no longer need
named modules
+1
MM: script type=module would inherit the special termination rules
of /script, whereas old browsers might not handle module the same
way, since that tag name doesn't mean anything special in old browsers
AR: script type=module means the browser won't even try to parse
it as JS, which is what we want [so that we can execute the script
contents as a module, via some sort of polyfill]
DH: script type=worker might also need to have the script
type=module semantics, and type= attribute syntax makes it hard to
mix and match those attributes; maybe script worker module would be
better? (i.e. the type attribute values become optional value-less
attribute names)
DH: The difference between script type=module and module is that
as long as there's … you always have the option of writing
scriptSystem.import(main.js)/script
TODO: Get DH to clarify this point when we edit the notes.
cc'ing Dave Herman for this part.
AR: [note taker (BN) may be misinterpreting] The JS API remains
important even when we have HTML sugar.
Was this part edited after the misinterpretation or is it the original
note?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 6 June 2014 TC39 Meeting Notes
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 6 June 2014 TC39 Meeting Notes
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 to seeing these slides. Andy I don't know if these slides are the final version which was presented at the meeting: https://docs.google.com/a/netflix.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU And related: https://github.com/jhusain/asyncgenerator - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
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 are a great idea. I'd also like to echo the comments that ES6 modules seem well designed, looking forward to native implementations. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 4 June 2014 TC39 Meeting Notes
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 acceptable. Obviously we should try to make the path of least resistance be good interface design; WebIDL aimed at that from the start. It doesn't help that the concept of good interface design is not universally agreed on and not time-invariant So with that in mind, we want something that will allow us to express existing DOM APIs (which are by and large not good interface design in various ways), something that allows us to express whatever people actually want to express (and we better come to some agreement about what that is), and a way to transition from the current WebIDL to the new thing with minimal pain in some way, both in terms of rewriting all the existing specs that use WebIDL and browser implementations that do. This all would have been way easier 3-4 years ago when WebIDL was first being put together. :( -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Standard builtins' prototypes and toString
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.
To resolve this, I propose changing these `toString` to first check if the
`this` value is %FooPrototype% (e.g., %DatePrototype% in the case at hand)
and return the result of the equivalent of calling the original
Object.prototype.toString.
I'm not sure if that is enough to cover subclasses of these builtins. Will
calling `toString` on the prototype of `class MyDate extends Date{}` still
throw? If so, that would at least not be a backwards-compatibility concern,
but it's probably also not desirable.
till
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
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 provided that functionality. It doesn't seem to me like a pattern we should want to encourage. I think it was meant for functional programming; but FP is so poorly supported by the rest of the standard library that it's not useful by itself. Array.of could test 'if the this value is undefined' rather than using IsConstructor(). I like that. I can't put my finger on it, but I suspect people will try to treat Array.of as a standalone function and get the undefined is not a constructor error, and be baffled. 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. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
[no subject]
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
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 12, 2014 at 2:22 AM, David Bruant bruan...@gmail.com wrote:
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
syntax) from other (named) modules.
Just to be sure I understand, with module (or script type=module),
the module has to be named? So module never really makes sense on its own
and should always have a name attribute?
DH: module name=qux creates race conditions with HTML imports (part
of WebComponents).
YK: People who saw named HTML module tags though you should mix html
imports w named module imports
YK: When you have packaging solution (SPDY, etc), you no longer need
named modules
+1
MM: script type=module would inherit the special termination rules of
/script, whereas old browsers might not handle module the same way,
since that tag name doesn't mean anything special in old browsers
AR: script type=module means the browser won't even try to parse it
as JS, which is what we want [so that we can execute the script contents as
a module, via some sort of polyfill]
DH: script type=worker might also need to have the script
type=module semantics, and type= attribute syntax makes it hard to mix
and match those attributes; maybe script worker module would be better?
(i.e. the type attribute values become optional value-less attribute names)
DH: The difference between script type=module and module is that as
long as there's … you always have the option of writing
scriptSystem.import(main.js)/script
TODO: Get DH to clarify this point when we edit the notes.
cc'ing Dave Herman for this part.
AR: [note taker (BN) may be misinterpreting] The JS API remains important
even when we have HTML sugar.
Was this part edited after the misinterpretation or is it the original
note?
David
___
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: 6 June 2014 TC39 Meeting Notes
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 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 12, 2014 at 2:22 AM, David Bruant bruan...@gmail.com wrote:
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
syntax) from other (named) modules.
Just to be sure I understand, with module (or script type=module),
the module has to be named? So module never really makes sense on its own
and should always have a name attribute?
DH: module name=qux creates race conditions with HTML imports (part
of WebComponents).
YK: People who saw named HTML module tags though you should mix html
imports w named module imports
YK: When you have packaging solution (SPDY, etc), you no longer need
named modules
+1
MM: script type=module would inherit the special termination rules of
/script, whereas old browsers might not handle module the same way,
since that tag name doesn't mean anything special in old browsers
AR: script type=module means the browser won't even try to parse it
as JS, which is what we want [so that we can execute the script contents as
a module, via some sort of polyfill]
DH: script type=worker might also need to have the script
type=module semantics, and type= attribute syntax makes it hard to mix
and match those attributes; maybe script worker module would be better?
(i.e. the type attribute values become optional value-less attribute names)
DH: The difference between script type=module and module is that as
long as there's ... you always have the option of writing
scriptSystem.import(main.js)/script
TODO: Get DH to clarify this point when we edit the notes.
cc'ing Dave Herman for this part.
AR: [note taker (BN) may be misinterpreting] The JS API remains important
even when we have HTML sugar.
Was this part edited after the misinterpretation or is it the original
note?
David
___
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: 5 June 2014 TC39 Meeting Notes
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 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868? which may have bearing.
Ideally module does not use script's insane parsing rules, but there is a
lot of complex stuff there that I don't think I fully grasp.
Also, David: modules are not named; you cannot import them. Check out
https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md
From: es-discuss es-discuss-boun...@mozilla.org on behalf of John Barton
johnjbar...@google.com
Sent: Thursday, June 12, 2014 10:02
To: David Bruant
Cc: Ben Newman; es-discuss
Subject: Re: 5 June 2014 TC39 Meeting Notes
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 12, 2014 at 2:22 AM, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
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 syntax) from other (named)
modules.
Just to be sure I understand, with module (or script type=module), the
module has to be named? So module never really makes sense on its own and
should always have a name attribute?
DH: module name=qux creates race conditions with HTML imports (part of
WebComponents).
YK: People who saw named HTML module tags though you should mix html imports w
named module imports
YK: When you have packaging solution (SPDY, etc), you no longer need named
modules
+1
MM: script type=module would inherit the special termination rules of
/script, whereas old browsers might not handle module the same way, since
that tag name doesn't mean anything special in old browsers
AR: script type=module means the browser won't even try to parse it as JS,
which is what we want [so that we can execute the script contents as a module,
via some sort of polyfill]
DH: script type=worker might also need to have the script type=module
semantics, and type= attribute syntax makes it hard to mix and match those
attributes; maybe script worker module would be better? (i.e. the type
attribute values become optional value-less attribute names)
DH: The difference between script type=module and module is that as long
as there's ... you always have the option of writing
scriptSystem.import(main.js)/script
TODO: Get DH to clarify this point when we edit the notes.
cc'ing Dave Herman for this part.
AR: [note taker (BN) may be misinterpreting] The JS API remains important even
when we have HTML sugar.
Was this part edited after the misinterpretation or is it the original note?
David
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
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() { return this.y; },
toString() {
return `${this.getX()},${this.getY()}`;
}
}
or equivalently enough in ES5
function Point(x, y) {
this.x = x;
this.y = y;
}
Point.prototype = {
getX: function() { return this.x; },
getY: function() { return this.y; },
toString: function() {
return '' + this.getX() + ',' + this.getY() + '';
}
};
alert(Point.prototype) alerts undefined,undefined. Ok, this specific
example doesn't throw, but equally simple and plausible examples would.
On Thu, Jun 12, 2014 at 5:26 AM, Till Schneidereit
t...@tillschneidereit.net 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.
To resolve this, I propose changing these `toString` to first check if the
`this` value is %FooPrototype% (e.g., %DatePrototype% in the case at hand)
and return the result of the equivalent of calling the original
Object.prototype.toString.
I'm not sure if that is enough to cover subclasses of these builtins. Will
calling `toString` on the prototype of `class MyDate extends Date{}` still
throw? If so, that would at least not be a backwards-compatibility concern,
but it's probably also not desirable.
till
___
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: IsConstructor
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); //Equivalent to: Array.of(1,2,3,4,5)
I don't recall why we provided that functionality. It doesn't seem to me
like a pattern we should want to encourage.
I think it was meant for functional programming; but FP is so poorly
supported by the rest of the standard library that it's not useful by
itself.
Array.of could test 'if the this value is undefined' rather than using
IsConstructor(). I like that. I can't put my finger on it, but I
suspect people will try to treat Array.of as a standalone function and
get the undefined is not a constructor error, and be baffled.
The problem with the undefined test is that it doesn't work if somebody tries
to attach such functions to a namespace object:
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
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
Re: Standard builtins' prototypes and toString
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 recognition. Please forgive the typos.
On Jun 12, 2014, at 10:57 AM, Mark S. Miller erig...@google.com wrote:
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() { return this.y; },
toString() {
return `${this.getX()},${this.getY()}`;
}
}
or equivalently enough in ES5
function Point(x, y) {
this.x = x;
this.y = y;
}
Point.prototype = {
getX: function() { return this.x; },
getY: function() { return this.y; },
toString: function() {
return '' + this.getX() + ',' + this.getY() + '';
}
};
alert(Point.prototype) alerts undefined,undefined. Ok, this specific
example doesn't throw, but equally simple and plausible examples would.
On Thu, Jun 12, 2014 at 5:26 AM, Till Schneidereit
t...@tillschneidereit.net 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.
To resolve this, I propose changing these `toString` to first check if the
`this` value is %FooPrototype% (e.g., %DatePrototype% in the case at hand)
and return the result of the equivalent of calling the original
Object.prototype.toString.
I'm not sure if that is enough to cover subclasses of these builtins. Will
calling `toString` on the prototype of `class MyDate extends Date{}` still
throw? If so, that would at least not be a backwards-compatibility concern,
but it's probably also not desirable.
till
___
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
___
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 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 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868 which may have bearing. Ideally module does not use script's insane parsing rules, but there is a lot of complex stuff there that I don't think I fully grasp. 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. -- Cheers, --MarkM ___ 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.
From: Allen Wirfs-Brock al...@wirfs-brock.com
Sent: Thursday, June 12, 2014 10:59
To: Jason Orendorff
Cc: Domenic Denicola; EcmaScript
Subject: Re: IsConstructor
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); //Equivalent to: Array.of(1,2,3,4,5)
I don't recall why we provided that functionality. It doesn't seem to me
like a pattern we should want to encourage.
I think it was meant for functional programming; but FP is so poorly
supported by the rest of the standard library that it's not useful by
itself.
Array.of could test 'if the this value is undefined' rather than using
IsConstructor(). I like that. I can't put my finger on it, but I
suspect people will try to treat Array.of as a standalone function and
get the undefined is not a constructor error, and be baffled.
The problem with the undefined test is that it doesn't work if somebody tries
to attach such functions to a namespace object:
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
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
RE: 5 June 2014 TC39 Meeting Notes
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 talking about. From what I'm aware of there are quite a lot of different insanities; but I am fuzzy on the details. Does anyone know which rules are inherently necessary, and which are historical accidents or constraints? ___ 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
To resolve this, I propose changing these `toString` to first check if the
`this` value is %FooPrototype% (e.g., %DatePrototype% in the case at hand)
and return the result of the equivalent of calling the original
Object.prototype.toString.
that breaks if you move such methods across Realms.
I'm not sure if that is enough to cover subclasses of these builtins. Will
calling `toString` on the prototype of `class MyDate extends Date{}` still
throw? If so, that would at least not be a backwards-compatibility concern,
but it's probably also not desirable.
Yes, it would still throw for subclasses.
I think the pattern we should follow for such built-in toString methods is that
if a branding check of this sort is performed, the fall back should be to
perform the built-in Object.prototype.toString behavior rather than throwing.
Unless somebody sees issues with this fix, I'll incorporate it into the spec.
for Date and RegExp.
Of course, even with this fix there is no guarantee that invoking toString on
an object won't throw. Debugging tool that expect to use toString need to take
that into account and provide their own fallbacks.
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 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, `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
To resolve this, I propose changing these `toString` to first check if
the `this` value is %FooPrototype% (e.g., %DatePrototype% in the case at
hand) and return the result of the equivalent of calling the original
Object.prototype.toString.
that breaks if you move such methods across Realms.
Good point.
I'm not sure if that is enough to cover subclasses of these builtins.
Will calling `toString` on the prototype of `class MyDate extends Date{}`
still throw? If so, that would at least not be a backwards-compatibility
concern, but it's probably also not desirable.
Yes, it would still throw for subclasses.
I think the pattern we should follow for such built-in toString methods is
that if a branding check of this sort is performed, the fall back should be
to perform the built-in Object.prototype.toString behavior rather than
throwing.
That's what I was trying to say above, yes. The exact means of the branding
are less important, I think.
Unless somebody sees issues with this fix, I'll incorporate it into the
spec. for Date and RegExp.
Of course, even with this fix there is no guarantee that invoking toString
on an object won't throw. Debugging tool that expect to use toString need
to take that into account and provide their own fallbacks.
Sure. This has always been the case and is, I guess, just a consequence of
how methods work in JS.
___
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: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, `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
WeakMap, Map, Set, others?
To resolve this, I propose changing these `toString` to first check if
the `this` value is %FooPrototype% (e.g., %DatePrototype% in the case at
hand) and return the result of the equivalent of calling the original
Object.prototype.toString.
that breaks if you move such methods across Realms.
I'm not sure if that is enough to cover subclasses of these builtins.
Will calling `toString` on the prototype of `class MyDate extends Date{}`
still throw? If so, that would at least not be a backwards-compatibility
concern, but it's probably also not desirable.
Yes, it would still throw for subclasses.
I think the pattern we should follow for such built-in toString methods is
that if a branding check of this sort is performed, the fall back should be
to perform the built-in Object.prototype.toString behavior rather than
throwing.
Unless somebody sees issues with this fix, I'll incorporate it into the
spec. for Date and RegExp.
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.
Of course, even with this fix there is no guarantee that invoking toString
on an object won't throw. Debugging tool that expect to use toString need
to take that into account and provide their own fallbacks.
Allen
___
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: IsConstructor
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 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.
There's a lot of subtle stuff going on with these compatibility cases and
addressing them was something we needed to do to get consensus around
supporting subclassing of Array. I don't think we want to mess them up simply
to avoid spec. level use of IsConstructor. I really don't expect anybody to
seriously try to self-host the compatibility aspects of those methods and there
is little point in trying to do a ES5 level shim that includes that
functionality because other aspects of of subclassing just won't work in ES5.
Allen
From: Allen Wirfs-Brock al...@wirfs-brock.com
Sent: Thursday, June 12, 2014 10:59
To: Jason Orendorff
Cc: Domenic Denicola; EcmaScript
Subject: Re: IsConstructor
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); //Equivalent to: Array.of(1,2,3,4,5)
I don't recall why we provided that functionality. It doesn't seem to me
like a pattern we should want to encourage.
I think it was meant for functional programming; but FP is so poorly
supported by the rest of the standard library that it's not useful by
itself.
Array.of could test 'if the this value is undefined' rather than using
IsConstructor(). I like that. I can't put my finger on it, but I
suspect people will try to treat Array.of as a standalone function and
get the undefined is not a constructor error, and be baffled.
The problem with the undefined test is that it doesn't work if somebody tries
to attach such functions to a namespace object:
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
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
Re: Standard builtins' prototypes and toString
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 ___ 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 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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868 which may have
bearing. Ideally module does not use script's insane parsing rules, but
there is a lot of complex stuff there that I don't think I fully grasp.
So you are saying that you want something better, something less complex
that you can fully grasp. In my opinion, that option already exists:
scriptSystem.import('moduleName').then(more-code);/script. A module
tag won't have those properties for the same reasons script is insane now.
jjb
___
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: 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 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, 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
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: IsConstructor
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 :-) ___ 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: 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 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: Standard builtins' prototypes and toString
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 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 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 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 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 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() 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
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: 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
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 erik.arvids...@gmail.com 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 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
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
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
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, 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 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 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: Re: Rationale for dropping ModuleImport syntax?
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 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: Re: Rationale for dropping ModuleImport syntax?
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 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: Standard builtins' prototypes and toString
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
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: IsConstructor
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 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: IsConstructor
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: 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 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. `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: Standard builtins' prototypes and toString
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 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: Standard builtins' prototypes and toString
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({})`.
(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: IsConstructor
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` 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: 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: 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
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({})`.
(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: Standard builtins' prototypes and toString
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
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: 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: 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
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: 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 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 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?
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 es-discuss-boun...@mozilla.org on behalf of Kevin Smith zenpars...@gmail.com 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: Re: Rationale for dropping ModuleImport syntax?
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 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: Standard builtins' prototypes and toString
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 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: IsConstructor
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 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: 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 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 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?
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 `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 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 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
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: 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
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.
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?
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?
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?
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: 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: 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 off...@gmail.com wrote: 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 `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 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 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: 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?
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 off...@gmail.com wrote: 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 `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 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 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?
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 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 off...@gmail.com wrote: 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 `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 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 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?
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 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 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?
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 calvin.metc...@gmail.com 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 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.
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 off...@gmail.com wrote:
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 `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 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
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
