.
On Aug 8, 2015, at 3:13 AM, Claude Pache claude.pa...@gmail.com wrote:
Le 6 août 2015 à 04:20, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com a écrit :
promises are fundamentally about chaining data together, not about
listening for events.
IMHO, promises are more about
bugs if the same promise were
returned for multiple calls to `.then` with the same callback.
On Tue, Aug 4, 2015 at 5:32 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
On Aug 4, 2015, at 1:32 PM, Andrea Giammarchi andrea.giammar...@gmail.com
mailto:andrea.giammar
of complexity with unclear goals.
Also to your question about adding multiple handlers, if that handler has
side-effects, then it would definitely cause bugs if the same promise were
returned for multiple calls to `.then` with the same callback.
On Tue, Aug 4, 2015 at 5:32 PM, Glen Huang curvedm
On Aug 4, 2015, at 1:32 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
only promises that has passed through their initialization the callback would
be cancelable,and this could be reflected through a `.cancelable` property
That's precisely the problem. When you made a mistake
-spec/issues/16
https://github.com/promises-aplus/cancellation-spec/issues/16.
what do you think about it?
2015年8月3日(月) 8:43 Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com:
I was discussing with Jake Archibald about cancelable promises the other day.
I was trying
, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/2/15 8:43 PM, Glen Huang wrote:
You can think it as that each promise keeps a list of its child promises,
when the same callback is passed to .ignore() it sets a flag on the
corresponding child promise so that when itself resolves/rejects, it won't
I was discussing with Jake Archibald about cancelable promises the other day. I
was trying to convince him promise.cancel() might not be a good idea. But that
conversation unfortunately leans more towards on how the abort API should be
exposed on fetch. I did provide some thoughts on that
, Brendan Eich bren...@mozilla.org wrote:
Glen Huang wrote:
maybe subclassing that particular class is not the correct abstraction here;
I think the need for inheriting methods and the need for a totally different
way of preparing the object are orthogonal.
There's a saying taught (I'm told
maybe subclassing that particular class is not the correct abstraction here;
I think the need for inheriting methods and the need for a totally different
way of preparing the object are orthogonal.
correct the design of the super-constructor, so that it is able to just do
the minimum
Thanks for the reply.
it is IMHO a good thing
I like the way you call the old way of doing things clunky and super shiny
(no sarcasm intended). :)
However, forcing super has one major drawback: it becomes cumbersome when you
don't want to call superclass's constructor(), that you want to
Not hastening to get an answer. Just want to make sure I didn't ask a question
with an incorrect premise.
Thanks for the reminding, very assuring.
On May 11, 2015, at 11:34 AM, Edwin Reynoso eor...@gmail.com wrote:
Give it time, people don't check this everyday, and if they do. Wait till
No one care to comment? Hope I didn't mistake how super works.
On May 8, 2015, at 11:05 AM, Glen Huang curvedm...@gmail.com wrote:
TLDR: If `this` is used without `super` (which should be statically
analyzable), let it refer to Object.create(new.target.prototype). Otherwise,
let super
Isn't super-constructor null in this case?
From step 4 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-getsuperconstructor
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-getsuperconstructor
superConstructor is C.[[GetPrototypeOf]]()
which should be `null` after the
{
constructor() {
let _this = Object.create(new.target.prototype);
return _this;
}
}
```
Anyway to use `this` here? Having to use a different name is a bit painful.
On May 7, 2015, at 6:55 PM, Claude Pache claude.pa...@gmail.com wrote:
Le 7 mai 2015 à 11:49, Glen Huang curvedm
TLDR: If `this` is used without `super` (which should be statically
analyzable), let it refer to Object.create(new.target.prototype). Otherwise,
let super creates what it refers to.
I know the reason to force `super` in derived class's constructor is to make
sure `this` refers to the exotic
The point is to keep the binding:
```js
export default let a = 1;
a = 2;
```
exports value 2
```js
let a = 1
export default a;
a = 2;
```
exports value 1
On May 6, 2015, at 1:18 PM, Bucaran jbuca...@me.com wrote:
Read as much as I could, but it was getting too long, so just to quickly
at the bottom.
On May 6, 2015, at 2:33 PM, Glen Huang curvedm...@gmail.com wrote:
The point is to keep the binding:
```js
export default let a = 1;
a = 2;
```
exports value 2
```js
let a = 1
export default a;
a = 2;
```
exports value 1
On May 6, 2015, at 1:18 PM, Bucaran jbuca
, Glen Huang curvedm...@gmail.com wrote:
let a = 1;
setTimeout(() = a = 2, 100);
export default a;
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
/2333
https://github.com/eslint/eslint/issues/2333
On Apr 17, 2015, at 8:17 PM, Mathias Bynens mathi...@opera.com wrote:
On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang curvedm...@gmail.com wrote:
I've completely replaced var with let in my es 2015 code, but I noticed
most variables I
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com wrote:
```js
do {
let a = 1;
} while (a);
```
is a undefined in the while condition? This seems like a gotcha.
___
es-discuss mailing list
es-discuss@mozilla.org
https
lexically scoped variables declared in a block are
accessible outside of that block? Java, C, C#, rust, Python, etc, will not
let you do this. I’m not sure this is a gotcha for most software developers
On Apr 17, 2015, at 10:57 AM, Glen Huang curvedm...@gmail.com wrote:
```js
do {
let
Thank you.
I just post my new understanding a few seconds earlier. Hope that's right. :)
On Apr 17, 2015, at 11:28 PM, Andreas Rossberg rossb...@google.com wrote:
On 17 April 2015 at 17:18, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Not sure about others, but i
You guys are talking about referencing the global object in modules right?
Since in scripts you can reliably get hold of the global object by using this
in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope of a
module, I guess that means module code really
I've completely replaced var with let in my es 2015 code, but I noticed
most variables I introduced never change.
Should I replace them with const? Will there be any performance gain for most
browsers? If so, should such performance gain be considered micro optimization?
case for importing a
module without binding it to an identifier?
On Mar 17, 2015, at 12:37 AM, caridy car...@gmail.com wrote:
inline
On Mar 16, 2015, at 2:21 AM, Glen Huang curvedm...@gmail.com wrote:
On second thought, this does seem to imply that polyfills can’t use the
module syntax
, written
in module syntax, in the polyfill that can later be reuse by the project
(without converting the library to script syntax and duplicate the code in the
end of cause)?
On Mar 16, 2015, at 11:56 AM, Glen Huang curvedm...@gmail.com wrote:
Didn’t know about the service. It looks really
, modules will have access to window, and any other runtime feature.
no, I don't recommend using modules to patch the runtime, features should
probably be patched before attempting to load any module (maybe using FT
polyfill service).
/caridy
On Mar 15, 2015, at 10:57 PM, Glen Huang
My guess is that it’s for importing modules that expose objects via the global
object (e.g., window).
However I do have a question: is it possible for a module to access the global
object without relying on the host environment?
One use case is to polyfill the language's standard library.
In nodejs you can require a json file directly to get its value: `var value =
require(“./package.json”)`.
Is there an equivalent construct in es2015? Or developers have to turn it into
a module before it can be imported?
___
es-discuss mailing list
://github.com/whatwg/loader/issues/new, we will be happy to provide
more details since this has nothing to do with ES2015 specifications.
/caridy
On Feb 26, 2015, at 3:24 AM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
In nodejs you can require a json file directly
Thanks for the examples. But I wonder why beat around the bush and not let
developers express exactly what they want?
On Feb 20, 2015, at 5:51 PM, Leon Arnott leonarn...@gmail.com wrote:
Ah, right, my apologies for misreading.
So... I think this scenario would be better served if ES7 had
Since we required methods defined within class definitions non-enumerable by
default, I think we should discourage people to do things like:
class Foo { … }
bar = () = {}
Foo.prototype.bar = bar;
Foo.prototype.addtionalMethod = () = {}
Maybe two new syntaxes could be allowed in es7?
class Foo
You mean Object.assign to Foo.prototype?
```
class Foo { ... }
Object.assign(Foo.prototype, {
bar, /* Existing method */
additionalMethod() { ... }, /* New method */
});
```
If I’m not wrong, methods added like this are enumerable.
On Feb 20, 2015, at 5:21 PM, Leon Arnott
I believe this is out the scope of ecmascript. It’s up to the host to determine
how the paths are resolved.
See
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-hostnormalizemodulename
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-hostnormalizemodulename
On Feb 5, 2015,
. What's the problem
you're thinking of, exactly?
/be
Glen Huang wrote:
I was saying that a feature like lightweight traits is probably
impossible to desugar to es5, if class syntax makes properties and
methods non-enum.
___
es-discuss mailing
into a string altogether.
On Dec 24, 2014, at 12:44 PM, Brendan Eich bren...@mozilla.org wrote:
Clever -- treat the cooked values as raw. Should work -- test in Traceur?
/be
Glen Huang wrote:
On second thought, make it could be just as simple as this?
function tag(templateObj, ..args
Just my 2 cents:
1. Rick’s field test approach is epic. Encourage me to get my hands dirty. :)
However, the conclusion I get from these tests is that not many developers
explicitly set things to be non-enumerable. This does not directly translate to
“many developers care about prototype
that is it a good idea to add a
sprintf-like function to es6?
On Dec 25, 2014, at 2:39 AM, Brendan Eich bren...@mozilla.org wrote:
Glen Huang wrote:
I think I had been doing the whole thing wrong.
That is unclear, but it's clear to me that template strings in ES6 (including
String.raw
understanding evolves, I think I'm in agreement with Brendan and Yehuda (and
whoever else) that: enumerable in obj lit, non-enumerable in class body is
reasonable path forward.
Rick
On Wed, Dec 24, 2014 at 9:21 PM Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Just my 2 cents
Thanks for the suggestion.
You inspired me to realize that the basic idea shouldn’t be to find a way to
intersperse two arrays, but to find a way to undo the tagging of template.
so `template` === tag`template`, where tag = (templateObj, …args) =
untag(templateObj, …args)
If you intend to put
On second thought, make it could be just as simple as this?
function tag(templateObj, ..args) {
return String.raw({raw: templateObj}, …args);
}
On Dec 24, 2014, at 7:39 AM, Brendan Eich bren...@mozilla.org wrote:
Perhaps the most elegant way is functional composition on arrays, not
There was some heated debate on twitter too just yesterday:
https://twitter.com/domenic/status/547146484479561730
https://twitter.com/domenic/status/547146484479561730
Just wondering, is es6 class frozen? In those tweets Brendan proposed enum in
obj lit, not in class”. Looks like class is still
bren...@mozilla.org wrote:
Clever -- treat the cooked values as raw. Should work -- test in Traceur?
/be
Glen Huang wrote:
On second thought, make it could be just as simple as this?
function tag(templateObj, ..args) {
return String.raw({raw: templateObj}, …args
Actually mixins shouldn’t be done with Object.assign if that’s what you mean.
I think the language should provide a syntax for that (e.g., Lightweight traits
on http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/
http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/)
Although I guess it’s not very easy to desugar to es5 if there is no way to
enumerate prototype methods/properties. (probably impossible?)
On Dec 24, 2014, at 1:17 PM, Glen Huang curvedm...@gmail.com wrote:
Actually mixins shouldn’t be done with Object.assign if that’s what you mean.
I
How?
Given that you don’t know the names of the prototype properties and methods
contained (could be deep in the prototype chain) in a object. How do you add
these to another object?
On Dec 24, 2014, at 1:50 PM, Gary Guo nbdd0...@hotmail.com wrote:
Object.defineProperty could easily do
I guess it’s probably a misunderstanding.
I was saying that a feature like lightweight traits is probably impossible to
desugar to es5, if class syntax makes properties and methods non-enum.
On Dec 24, 2014, at 1:50 PM, Gary Guo nbdd0...@hotmail.com wrote:
Object.defineProperty could easily
Oh, forget about those. Thanks. Then problem solved.
non-enum class syntax + trait syntax. This could make prototypal inheritance a
joy to write. :)
On Dec 24, 2014, at 2:02 PM, Kevin Smith zenpars...@gmail.com wrote:
Given that you don’t know the names of the prototype properties and
Although when desugaring to es5, no need to consider symbol properties.
On Dec 24, 2014, at 2:02 PM, Kevin Smith zenpars...@gmail.com wrote:
getPrototypeOf
___
es-discuss mailing list
es-discuss@mozilla.org
In that case we have a gotcha.
Is there any interest to change that behavior? Since es6 isn’t finial yet.
On Dec 22, 2014, at 9:29 PM, Gary Guo nbdd0...@hotmail.com wrote:
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang curvedm...@gmail.com wrote:
Ideally it shouldn’t, because its twin
AM, Glen Huang curvedm...@gmail.com wrote:
In that case we have a gotcha.
Is there any interest to change that behavior? Since es6 isn’t finial yet.
On Dec 22, 2014, at 9:29 PM, Gary Guo nbdd0...@hotmail.com
mailto:nbdd0...@hotmail.com wrote:
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang
When a template is passed to a function, what’s the quickest way to return a
string with additional arguments being interpolated into the template?
For example,
```
minify`
ul
li${content}/li
/ul
`
```
In this case`minify` will return the minified html, but
, [[ExportName]]: default}.
Vice versa for LexicalDeclaration.
On Dec 16, 2014, at 3:50 PM, Glen Huang curvedm...@gmail.com wrote:
With the help of your explanation, the spec becomes much easier to read.
Thanks.
Would you consider adding this:
Syntax
export default var
wrote:
On Dec 16, 2014, at 12:07 AM, Glen Huang wrote:
A little tweak:
Syntax
export default var VariableDeclaration;
ExportEntries
Let names be the BoundNames of VariableDeclaration.
Let localName be the sole element of names.
Return a new List containing the Record
To rephrase the problem:
Assuming `next` was never defined.
```js
let a = { next() { next() } };
a.next();
```
The result of running this code is runtime error or infinite recursion?
I tried to find the answer in the spec, but the initialization and calling of a
function object is a bit
2014 at 11:03:43 PM Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
To rephrase the problem:
Assuming `next` was never defined.
```js
let a = { next() { next() } };
a.next();
```
The result of running this code is runtime error or infinite recursion?
I tried to find
complain. :)
On Dec 17, 2014, at 12:32 PM, Glen Huang curvedm...@gmail.com wrote:
Got it. Thank you.
Was kinda hoping I was wrong though.
```js
let next = () = console.log(1);
let a = { next() { console.log(2); next() } };
a.next();
```
I guess people would incline to guess
What about this:
export default var a, b, c;
is equivalent to
var a;
export default a;
export var b, c;
On Dec 13, 2014, at 12:44 PM, Kevin Smith zenpars...@gmail.com wrote:
From https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports
.
Why do you want this?
On Mon, Dec 15, 2014, 09:41 Caridy Patino car...@gmail.com
mailto:car...@gmail.com wrote:
No.
On Dec 15, 2014, at 6:26 AM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
What about this:
export default var a, b, c;
is equivalent
, and I
now know why. Thanks again.
On Dec 15, 2014, at 11:31 PM, Dave Herman dher...@mozilla.com wrote:
On Fri, Dec 12, 2014 at 8:19 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
You can already do var a = 1;export default a;”. Why not make export
default var
very good at reading EBNF
Marius Gundersen
On Mon, Dec 15, 2014 at 4:31 PM, Dave Herman dher...@mozilla.com
mailto:dher...@mozilla.com wrote:
On Fri, Dec 12, 2014 at 8:19 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
You can already do var a = 1;export default
Thank you so much. It’s now crystal clear. :)
On Dec 16, 2014, at 12:25 AM, Dave Herman dher...@mozilla.com wrote:
On Mon, Dec 15, 2014 at 8:16 AM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
So giving the experience of you can merge export and a variable
to bind variables with the “export default”
syntax, when it is used to export an object?
```js
export default function a() {}
a = 2;
```
(This should be 2, right?)
On Dec 16, 2014, at 12:25 AM, Dave Herman dher...@mozilla.com wrote:
On Mon, Dec 15, 2014 at 8:16 AM, Glen Huang curvedm
@Kevin @Brendan
Thanks for the detailed explanation. If I’m not wrong, the exported binding is
the module record in the spec, right?
Also sorry for the confusion about the “object” concept I mentioned. By
“object”, I mean anything qualifies as an AssignmentExpression” in the spec.
And after
With the help of your explanation, the spec becomes much easier to read. Thanks.
Would you consider adding this:
Syntax
export default var VariableDeclaration;
ExportEntries
Let entries be a new empty List.
Let name be the BoundNames of VariableDeclaration.
Repeat for each name in
But allowing getter setter already makes it dangerous:
let _bar = {}
class Foo {
static get bar() { return _bar; }
}
Objects that have Foo.prototype in the prototype chain can do this.bar.a = 1,
and the change won’t be shadowed.
I found myself looking for a way to define static
({hidden: false}, options);
}
}
class HiddenMenu extends Menu {
constructor(options){
super(Object.assign({hidden: true}, options));
}
}
On Sat, Dec 13, 2014 at 2:54 AM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
But allowing getter
this, you should also put a comment saying Modify
Menu.defaults to change the default settings. And put it in any docs that
go with it.
On Sat, Dec 13, 2014 at 3:35 AM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Thanks for the sample code.
But the defaults
2014 at 4:54:55 AM Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
But allowing getter setter already makes it dangerous:
let _bar = {}
class Foo {
static get bar() { return _bar; }
}
Objects that have Foo.prototype in the prototype chain can do this.bar.a =
1
Hi,
From https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports, it seems
that export default var a = 1;” is not valid in es6. I wonder why that’s the
case. You can already do var a = 1;export default a;”. Why not
Currently, es6 doesn’t seem to let you define static properties and prototype
properties with the class syntax, by that I mean this in es5:
function Foo() {}
Foo.bar = 1;
Foo.prototype.baz = 2;
Is it possible to allow this in es6 with the class syntax? Or it belongs to
es7? Or it’s simply a
I agree data properties on the instance prototype is a bad idea. But static
properties are really useful. Could we at lease allow them:
class Foo {
static bar = 43;
}
On Dec 13, 2014, at 12:53 PM, Kevin Smith zenpars...@gmail.com wrote:
function Foo() {}
Foo.bar = 1;
Foo.prototype.baz =
73 matches
Mail list logo
