Re: Allow for async/await to use global.Promise and not builtin Promise
Jordan Harband wrote > Anything "more efficient" would likely not be spec compliant Promises (also those specified in ES) are quite opinionated, and I believe we should have right to practice our own opinions in our own apps. On these grounds thenable objects (so not necessarily promise instances) are supported, and work seamlessly in promise chains. Unfortunately async/await breaks that support, it'll be great if we can recover from that. -- Sent from: http://mozilla.6506.n7.nabble.com/Mozilla-ECMAScript-4-discussion-f89340.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allow for async/await to use global.Promise and not builtin Promise
+1 This would allow injecting more efficient promise alternatives without transpilation of async/await -- Sent from: http://mozilla.6506.n7.nabble.com/Mozilla-ECMAScript-4-discussion-f89340.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.resolve
You'll find a solid explanantion here: https://github.com/tc39/ecma262/issues/544#issuecomment-275881668 Array.from, Array.of were designed in very early stage of ES2015, and fact that they work that way (while e.g. Promise.resolve does not), is now considered a mistake that was too late to revert at some point. -- Sent from: http://mozilla.6506.n7.nabble.com/Mozilla-ECMAScript-4-discussion-f89340.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Multi-index assignment.
Just do: ```js Object.assign(array, [0, 1]); ``` You can also omit some indexes (and they won't be overwritten with undefined). e.g. fill just index 3 and 5: ```js Object.assign(array, [,,,3,,5]); ``` -- Sent from: http://mozilla.6506.n7.nabble.com/Mozilla-ECMAScript-4-discussion-f89340.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Add timezone data to Date
Timezone data is already *indirectly* accessible via native Intl.DateTimeFormat (I've also once published an util that allows to work that: https://github.com/medikoo/date-from-timezone ). Still it would be way better if there's some direct access provided, whether it should be directly on Date or on Intl.DateTimeFormat is to be discussed (I would possibly vote for Intl.DateTimeFormat) -- View this message in context: http://mozilla.6506.n7.nabble.com/Add-timezone-data-to-Date-tp366272p366292.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Async functions not friendly to promise extensions
> var k = (async function() {await window.setTimeout(1000); return
randomPromiseSubtype})();
Assuming that setTmeout(1000) returns a promise, this code is equivalent to:
async function() {
return setTimeout(1000).then(function () {
return randomPromiseSubtype;
});
};
I definitely would not expect that k in such case resolves with promise of
type of randomPromiseSubtype, same as you never expect that
`setTimeout(1000).then()`may resolve with different promise types.
However if it's:
async function() {
return randomPromiseSubtypeTimeout(1000).then(function () {
return whateverPromise;
});
};
It'll be great if k resolves with promise that shares the constructor with
promise returned by randomPromiseSubtypeTimeout(1000).then(...). That's my
point
--
View this message in context:
http://mozilla.6506.n7.nabble.com/Async-functions-not-friendly-to-promise-extensions-tp364921p364926.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Async functions not friendly to promise extensions
> You seem to misunderstand what async functions do to be async, Your function has the same product as the following: > new Promise((acc, rej) => acc(extendedPromise)) Yes, I totally understand that, and it's clear to me that it's that way. In my post I question that design, as it seems to me that way nicer would be if it's as follows: If (isThenable(result)) return result; else return new Promise((resolve, reject) => resolve(result)); Or if above seems too liberal, then at least: if (isPromise(result)) return new result.constructor((resolve, reject) => resolve(result)); else return new Promise((resolve, reject) => resolve(result)); > By no means do async functions use the returned values as their way of > determining what type of promise they are: that'd break when using multiple returns with different types. > I hope this explains it a bit for you. Sorry, but it didn't explain much. What to you mean by "that'd break when using multiple returns with different types" ? Can you throw some simple example? -- View this message in context: http://mozilla.6506.n7.nabble.com/Async-functions-not-friendly-to-promise-extensions-tp364921p364924.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Async functions not friendly to promise extensions
While Promise methods and functions are friendly for it's extensions (or even
not direct extensions but just thenables), the async function will always
normalize it's result to instance of Promise, even it's ExtendedPromise,
e.g.:class ExtendedPromise extends Promise {};var extendedPromise = new
ExtendedPromise(function (resolve) { resolve();
});extendedPromise.then().constructor === ExtendedPromise // truevar asyncFn
= async function () { return extendedPromise; };asyncFn().constructor ===
ExtendedPromise // falseasyncFn().constructor === Promise // trueThat makes
it cumbersome if we work with promise extensions. What was the reasoning
behind such design?If not thenables in general, the promise extensions I
believe should be passed through (or copied via its constructor.resolve).
--
View this message in context:
http://mozilla.6506.n7.nabble.com/Async-functions-not-friendly-to-promise-extensions-tp364921.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Power operator, why does -2**3 throws?
ES is already not free from such cases, e.g. `!'property' in object` will also not resolve as most will expect. I understand and agree that case is ambigous and is problematic. It just feels very controversial to me that it was decided that this case will be handled differently than others that share exactly same problem. For those who are not aware of all such quirks/inconsistences it leaves feeling that language is unpredictable in its behaviors. On 10/18/2016 01:05 AM, medikoo wrote: > There are many other cases when with no parens involved, people have > different expectations on the outcome. > If expression looks ambigous the actual result always depends on operators > precedence, it's how language worked for years, and I don't remember any > big > problems due to that. > > > Jordan Harband wrote >> It's quite simple (as has already been stated): some people expect `-x ** >> y` to be `-(x ** y)`. Some expect it to be `(-x) ** y`. >> >> The early SyntaxError ensures that nobody is confused - programmers will >> immediately add parens to disambiguate. >> >> Avoiding a potential footgun for the next 50 years, at the insignificant >> cost of adding two characters so that it parses seems like a very cheap >> price to pay. >> >> On Tue, Oct 18, 2016 at 12:20 AM, medikoo < >> medikoo+mozilla.org@ >> > >> wrote: >> >>> I must say throwing here, instead of relying on math dictated operators >>> precedence looks really bad. >>> It's very surprising to those well experienced with the language, and >>> totally inconsistent with how operators worked so far (there is no >>> previous >>> case where one will throw for similar reason). >>> >>> Also argument that it's inconsistent with Math.pow(-2, 2), is total miss >>> in >>> my eyes. >>> I believe to most programmers `Math.pow(-2, 2)`, translates to >>> `(-2)**(2)` >>> and not to `-2**2`, >>> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b : >>> c)**(2)` and not to `a ? b : c**2` >>> >>> >>> >>> >>> -- >>> View this message in context: http://mozilla.6506.n7.nabble. >>> com/Power-operator-why-does-2-3-throws-tp359609p359731.html >>> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at >>> Nabble.com. >>> ___ >>> es-discuss mailing list >>> >> es-discuss@ >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> ___ >> es-discuss mailing list >> es-discuss@ >> https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > View this message in context: > http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359733.html > Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at > Nabble.com. > ___ > es-discuss mailing list > es-discuss@ > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@ https://mail.mozilla.org/listinfo/es-discuss -- View this message in context: http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359853.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Power operator, why does -2**3 throws?
There are many other cases when with no parens involved, people have different expectations on the outcome. If expression looks ambigous the actual result always depends on operators precedence, it's how language worked for years, and I don't remember any big problems due to that. Jordan Harband wrote > It's quite simple (as has already been stated): some people expect `-x ** > y` to be `-(x ** y)`. Some expect it to be `(-x) ** y`. > > The early SyntaxError ensures that nobody is confused - programmers will > immediately add parens to disambiguate. > > Avoiding a potential footgun for the next 50 years, at the insignificant > cost of adding two characters so that it parses seems like a very cheap > price to pay. > > On Tue, Oct 18, 2016 at 12:20 AM, medikoo < > medikoo+mozilla.org@ > > > wrote: > >> I must say throwing here, instead of relying on math dictated operators >> precedence looks really bad. >> It's very surprising to those well experienced with the language, and >> totally inconsistent with how operators worked so far (there is no >> previous >> case where one will throw for similar reason). >> >> Also argument that it's inconsistent with Math.pow(-2, 2), is total miss >> in >> my eyes. >> I believe to most programmers `Math.pow(-2, 2)`, translates to >> `(-2)**(2)` >> and not to `-2**2`, >> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b : >> c)**(2)` and not to `a ? b : c**2` >> >> >> >> >> -- >> View this message in context: http://mozilla.6506.n7.nabble. >> com/Power-operator-why-does-2-3-throws-tp359609p359731.html >> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at >> Nabble.com. >> ___ >> es-discuss mailing list >> > es-discuss@ >> https://mail.mozilla.org/listinfo/es-discuss >> > > ___ > es-discuss mailing list > es-discuss@ > https://mail.mozilla.org/listinfo/es-discuss -- View this message in context: http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359733.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Power operator, why does -2**3 throws?
I must say throwing here, instead of relying on math dictated operators precedence looks really bad. It's very surprising to those well experienced with the language, and totally inconsistent with how operators worked so far (there is no previous case where one will throw for similar reason). Also argument that it's inconsistent with Math.pow(-2, 2), is total miss in my eyes. I believe to most programmers `Math.pow(-2, 2)`, translates to `(-2)**(2)` and not to `-2**2`, same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b : c)**(2)` and not to `a ? b : c**2` -- View this message in context: http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359731.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why Number(symbol) crashes?
Allen, thanks for comprehensive answer, it's clear now. Still, I must agree with Michał, that introducing such inconsistency to language doesn't give good impression. It's like we try to build other language on top of language which we can't change. It's now even more difficult to explain language behaviors to newcomers. -- View this message in context: http://mozilla.6506.n7.nabble.com/Why-Number-symbol-crashes-tp359554p359653.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Why Number(symbol) crashes?
I was searching the archived but wasn't able to find the answer. What's the reasoning behind having Number(symbol) crash instead of returning NaN (as it's in case all other non-coercible values?). It feels not consistent. If someone can point me to some discussion that provided the reasoning I'd be grateful -- View this message in context: http://mozilla.6506.n7.nabble.com/Why-Number-symbol-crashes-tp359554.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The `super` keyword doesn't work as it should?
/#!/JoePea wrote > Is there any hard evidence of the performance cost of a dynamic super? So > far I've read in various places (for example the thread linked to by > @medikoo, Axel's 2ality article on super) about there being "overhead", > but > the articles haven't quantified or put into perspective the actual > performance cost. Is it really that bad? Adding any additional internal property for function that needs to be updated depending on circumstances, definitely will bring noticeable performance regression, and no-one would want to agree for that. Still, for me (at least now) it's not clear why it actually implies any cost (?) If /dynamic/, the super should bring not cost, as in clear thinking it's just pure keyword which forces no action/calculation from compiler/interpreter until the moment it's evaluated. It'll be great if someone clarifies that. -- View this message in context: http://mozilla.6506.n7.nabble.com/The-super-keyword-doesn-t-work-as-it-should-tp357032p357148.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The `super` keyword doesn't work as it should?
Joe, see this post: http://mozilla.6506.n7.nabble.com/Making-quot-super-quot-work-outside-a-literal-td90457.html#a90551 There are some explanations there on why super was implemented as something /static/ and not /dynamic/ -- View this message in context: http://mozilla.6506.n7.nabble.com/The-super-keyword-doesn-t-work-as-it-should-tp357032p357113.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Are ES6 modules in browsers going to get loaded level-by-level?
Thanks for clarifications, Still after reading your comments I have a feeling that providing ES6 modules to browsers (efficient way) will be much more cumbersome and tricky than it is to provide CJS ones now. This may lead to scenario when most of us (for easy serve of bundle), will prefer to transpile them into something else, but I hope that won't be the case. Another question raises about server support. People are relying on shared (or in cloud) hosting solutions. Do all popular servers (Apache, nginx, or http server in node.js) support HTTP/2 already? Is it easy to configure them to serve es6 modules efficient way? -- View this message in context: http://mozilla.6506.n7.nabble.com/Fwd-Are-ES6-modules-in-browsers-going-to-get-loaded-level-by-level-tp337040p338232.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are ES6 modules in browsers going to get loaded level-by-level?
It'll be great to have some more insight on this. To my knowledge when using ES6 modules as currently specified there's no way to introduce more than one module with one file. So technically, the only way to use them natively in browsers, would be to serve them separately. This raises the question. Is there any mean in sight, that will allow us to serve them as fast as we can serve hundreds of bundled and minimized CJS modules now? Because if not, then landscape looks troubling. As it means that to have same performance, we will need to transpile ES6 modules for browser into something else, even though browsers may support them natively. -- View this message in context: http://mozilla.6506.n7.nabble.com/Fwd-Are-ES6-modules-in-browsers-going-to-get-loaded-level-by-level-tp337040p338209.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: classes and enumerability
Rick, I don't think this kind of analysis while promising, will expose "real" values. I think most developers which took the step to use descriptors on everyday basis, uses factory tools like that one: https://www.npmjs.com/package/d e.g. alone in my packages you'll find hundreds (if not thousands) of properties defined on prototypes as "enumerable: false", but no single definition would be picked by your script. -- View this message in context: http://mozilla.6506.n7.nabble.com/classes-and-enumerability-tp329572p331212.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Array.prototype.contains
Domenic Denicola-2 wrote > Personally I think the more useful model to follow than > `String.prototype.contains` is `Set.prototype.has`. API wise, arrays have much more in common with strings than with sets. Thinking ES5, they're both array-likes, set isn't. They share `length` property, their values can be accessed through indexes arr[0], str[0], they share few method names (`indexOf`, `lastIndexOf`), and all non destructive array methods can be successfully executed on strings, while they won't work with sets. I think it would be more appropriate to stick with `arr.contains` especially that we already have `arr.indexOf` and `str.indexOf`, and both `indexOf` and `contains` share same signature. `arr.has` could be fine, if we also rename `str.contains` to `str.has`. -- View this message in context: http://mozilla.6506.n7.nabble.com/Array-prototype-contains-tp309926p310234.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
+1
It's very common use case. Recently I switched to Object.assign in my utils
lib, and needed to replace one function with two: `assign` and
`assignMultiple`. It doesn't look as nice now.
There are a lot of use cases for that, also one to do non-destructive merge
(via @pornelski):
Object.assign({}, foo, bar);
--
View this message in context:
http://mozilla.6506.n7.nabble.com/Object-assign-with-several-source-objects-tp303184p309055.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.from and sparse arrays
Brendan Eich-3 wrote > Allen Wirfs-Brock wrote: >> Do you have any real world use cases in mind that are driving the desire >> for >> Array.from to preserve sparseness? > > Use-cases for sparse arrays + copying them would be really helpful. It was more call for a consistency, as all other methods are gentle to sparse arrays, this one suddenly isn't and I was wondering what's the reason for that. It also brings confusion. I try to follow same patterns designing methods that are not part of a standard, and now it's hard to decide how to handle sparse arrays case, as it's in `map` or as in `from` (?) However if you ask me for real world cases for sparse arrays, none comes to my mind now. Personally I don't really use them (I think), but it'll be good to hear from others. -- View this message in context: http://mozilla.6506.n7.nabble.com/Array-from-and-sparse-arrays-tp308815p308837.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array.from and sparse arrays
Currently per spec Array.from doesn't produce perfect copies of sparse
arrays:
Array.from([1,,2]); // [1, undefined, 2]
I know it's been discussed [1] but there's not much feedback.
It doesn't seem right for a few reasons:
1. Array.from already produces sparse arrays from array-likes:
Array.from({ 0: 1, 2: 2, length: 3 }); // [1,,2]
So why it doesn't from sparse arrays?
2. Array.from can't be used as generic plain array copy producer.
In ES5 this can be achieved, with `arr.slice()`. However as in ES6 `slice`
will return object of same type as one on which it is called, so it is no
longer that straightforward, especially if we're strongly after plain array.
The only 100% bulletproof solutions we have in ES6 are either:
var plainCopy = new Array(arr.length)
arr.forEach(function (v, i) { plainCopy[i] = v; });
or other quite dirty way:
Array.from(Object.assign({ length: arr.length}, arr));
Other related question:
Why do array iterators go through not defined indexes? It seems not
consistent with other iteration methods we have since ES5, are there any
plans to use sparse iteration kinds [2] or are they defined just to reserve
eventual future use?
Thanks
-- Mariusz
[1]
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-28.md#arrayfrom
[2]
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-properties-of-array-iterator-instances
--
View this message in context:
http://mozilla.6506.n7.nabble.com/Array-from-and-sparse-arrays-tp308815.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin, why just for enumerables (?)
> It's a copy-paste error in the draft: > https://bugs.ecmascript.org/show_bug.cgi?id=1999#c1 Great news. Thanks! Sorry for noise. /Mariusz -- View this message in context: http://mozilla.6506.n7.nabble.com/Object-mixin-why-just-for-enumerables-tp293611p293623.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Object.mixin, why just for enumerables (?)
Object.mixin, why just for enumerables (?) This is related to: http://mozilla.6506.n7.nabble.com/Object-define-Object-mixin-tp265638p265651.html In a spec we have both Object.assign and Object.mixin. Object.assign is for copying properties ES3 way, which even in ES5 world is what you want in most cases (btw. I don't agree with http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/ For 3 years I work strictly with ES5, and I never had a case in which I wanted to just copy enumerables and preserve getters, it's highly unwanted in all cases I had). Object.mixin is for copying definitions, which I find as rare but also valid use case, e.g. to mimic multiple inheritance by copying properties from one prototype to other. However this cannot work as intended if it's limited just for enumerables. All properties in native prototypes are already defined as not enumerable, and this is also what I follow in my code when I define models. So as specified currently I find Object.mixin as a function that I don't find valid use case for, and I strongly miss something like Object.assignDefinitions, which will copy properties by descriptors, no matter whether they're enumerable or not. /Mariusz -- View this message in context: http://mozilla.6506.n7.nabble.com/Object-mixin-why-just-for-enumerables-tp293611.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises: final steps
While I can agree that "monitor" feature (that's proposed instead of `done`) has some benefits, I see it only as an aid for developers that are inexperienced with promises, or as a fallback for those experienced. It looks more as a smart add-on, which to be complete can't be implemented in plain JavaScript, is implementation specific and should be treated as optional. What's more important it still doesn't provide developer with full control of error handling on JavaScript level and that can be achieved only with `done`. I have problems understanding why such complex and not natural feature is favored over something so simple and straightforward. -- View this message in context: http://mozilla.6506.n7.nabble.com/Promises-final-steps-tp290303p290518.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Callable objects
Once there was a thread that discussed ability to configure any object as callable: http://mozilla.6506.n7.nabble.com/callable-objects-td99268.html Although it was then warmly welcomed, I don't see such possibility specified in latest draft I think it'll be really useful and we already deal with callable (and not functions) objects in some native interfaces. Is there any chance to bring @@call symbol or some other solution that would make that possible? -- View this message in context: http://mozilla.6506.n7.nabble.com/Callable-objects-tp290363.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Creating and consuming custom iterators
> There will be a public symbol (that you can import from a system module) that will allow you to do both things. There's no problem then. Thanks -- View this message in context: http://mozilla.6506.n7.nabble.com/Creating-and-consuming-custom-iterators-tp289598p289600.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Creating and consuming custom iterators
In ES5 there is a concept of array-like, which while probably too relaxed is really friendly for developers, as we can easily create custom array-like abstractions and make it consumable to any generic functions, methods that process array-likes. In ES6 there's more advanced (and definitely better) iterators concept, while I'm pretty excited by it, If read spec correctly I see it's quite limited and not that usable. 1 There's no way I can create custom iterator abstraction (How can I can define MyCustomIterator.prototype[@@iterator] method?). 2. There's no straightforward way to consume iterators in generic way, e.g. I want to write function that works in similar way as Set constructor, and accepts any iterator implementation. I don't have a means to call iterator[@@iterator] method. Please correct me if I'm wrong, but if it's the case, I think it's really important to open that. Maybe there should be Reflect.getIterator(obj) and Reflect.defineIterator(obj, getIterator) for that? -- View this message in context: http://mozilla.6506.n7.nabble.com/Creating-and-consuming-custom-iterators-tp289598.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Where'd Promise#done go?
Stating `then()` is something more advanced than `done()` doesn't make much sense to me. They're different methods, that serve different purpose, I think they should be valued on a similar level. Key thing is that *`then()` is conceptually a `map()`*, and there's something wrong if just to access the value we have to use `map()`. Second issue, mentioned already numerous times is not desired (in case of "just access") error suppression. -- View this message in context: http://mozilla.6506.n7.nabble.com/Where-d-Promise-done-go-tp281461p281520.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Where'd Promise#done go?
I use promises a lot, and (for all valid points stated above) I see `done` as a must have for implementation to be practically usable. Also it needs to be provided natively, as it's not possible to shim it just with `then`. Proposed log/un-log in background mechanism doesn't solve the issue, as you're still left with overhead of `then` and it complicates error handling which with `done` is straightforward. I hope it won't land in any spec. -- View this message in context: http://mozilla.6506.n7.nabble.com/Where-d-Promise-done-go-tp281461p281493.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Is __proto__ ready needed?
Object.setPrototypeOf is really needed. Use cases for that are as rare as for eval, but exist and are valid. Currently I work on database engine written in JavaScript, and rely quite heavily on __proto__. Once I was asked By David Herman to explain my use cases. I prepared following gist then: https://gist.github.com/medikoo/5602644 -- View this message in context: http://mozilla.6506.n7.nabble.com/Is-proto-ready-needed-tp281048p281061.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Promise/Future: asynchrony in 'then'
I think eventual synchronicity of `then` is just theoretical problem and in practice we face much bigger issues when we force asynchronicity. If we want to have "fast" asynchronicity, then we enter the problem of overloaded recurrence of next tick calls. It was already exposed by popular libraries: https://github.com/kriskowal/q/pull/259 https://github.com/tildeio/rsvp.js/issues/66 If we do it with setTimeout or setImmediate, then performance is significantly affected, and that diminishes the benefit of why we're actually using asynchronous calls. Promises while being aid for asynchronicity should not introduce any extra asynchronicity on it's own. Any optional next-tick resolution should be decided by user of library and not by library itself. If library forces it by design then we enter the world of issues like that one: https://github.com/cujojs/when/issues/135 I'm using promise library which few versions back moved away from forced next-tick resolution (mainly for performance reasons), and I didn't register any issues caused by that change. It actually confirmed me, that it's the way it should be. -- View this message in context: http://mozilla.6506.n7.nabble.com/Promise-Future-asynchrony-in-then-tp278846p279080.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
David, that's great clarification, and indeed it looks a bit different from that perspective. Still the only use case I see for freezing/sealing whole object (the way it works now) is when we expose some constant dictionary object on which each property counts, and that's very rare use case. I don't see much good in disallowing extensions to prototypes we expose. it's not JS way. We can prevent accidental modifications of *existing* API's but disallowing custom extensions is too restrictive and not friendly in my opinion. -- View this message in context: http://mozilla.6506.n7.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp272443p272674.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
