[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: 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: 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
