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 questio
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 tran
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
/#!/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 arti
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
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://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
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
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
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
> 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 Mozil
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
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 Ja
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 mos
> 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 - E
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
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 languag
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).
Als
gt; 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:
>
>>
thers 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 exp
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
Ex
> 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 tha
> 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
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 direct
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.htm
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.fr
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 method
+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
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 v
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 thousand
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
+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
http
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
33 matches
Mail list logo