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

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

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

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:

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

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

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

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

Re: Power operator, why does -2**3 throws?

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 expect

Re: Power operator, why does -2**3 throws?

g 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

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).

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

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

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

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:

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

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

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

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

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:

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

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

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 -

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

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

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

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

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

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

Re: Is __proto__ ready needed?

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

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:

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