Hello all,
In an effort to curtail the interesting behavior of Promise.resolve (especially
with regard to dynamic import), I have created a proposal for a well-known
symbol which will allow an object to not be treated as a "thenable."
I am privy to the current protocol proposal which might
> include a means of changing the key entirely.
>
> On Apr 12, 2018, at 9:33 PM, Gus Caplan <mailto:m...@gus.host>> wrote:
>
> Hello all,
>
> In an effort to curtail the interesting behavior of
> Promise
Hello all,
I just wanted to try and push this up again as this month's meeting approaches;
I would love for this to get a champion and be discussed.
-Gus
On 2018-04-12 20:33:15, Gus Caplan wrote:
> Hello all,
>
> In an effort to curtail the interesting behavior of P
If you use for-await syntax, the js implementation will internally use
GetIterator[1] which will look for Symbol.asyncIterator and if it can't find it
it will return an async wrapper around Symbol.iterator -Gus [1]:
https://tc39.github.io/ecma262/#sec-getiterator On Sun, 19 Aug 2018
16:34:
What is the reasoning behind wanting this data? For example, in exceptional
cases you should be creating errors which already have stacks containing this
information. -Gus On Thu, 23 Aug 2018 17:56:43 -0500 Aaron Gray
wrote I wondering what people think about the
idea of proposing be
Hello Kai, There are several members of TC39 who are also active with Node.js
development, and proposals do move through TC39 that come from needs in
Node.js, like the recent
https://github.com/guybedford/proposal-dynamic-modules. Moving forward, Node.js
has started an initiative to work more w
Shared memory doesn't need to "sync", its the same memory. Atomics exists to
provide primitives to help with timing (mostly race conditions). For example,
if you want to update an index in a SharedArrayBuffer (SAB) so that another
thread may read it, the safe way is to use Atomics.wait in the th
Please take a look at https://github.com/tc39/proposal-temporal
On Mon, Mar 4, 2019 at 3:30 PM Mark Davis ☕️ wrote:
> Sadly, time is not that simple. Most people using calendars consider the
> duration between January 15 and March 15 to be exactly 2 months. But such
> intervals are a different n
I always forget to reply-all :)
-- Forwarded message -
From: Gus Caplan
Date: Fri, Jun 21, 2019, 16:34
Subject: Re: ECMAScript feature suggestion: Streaming Array items through
filter/map/reduce functions
To: Roma Bronstein
I'm working on a proposal that adds genera
When we're dealing with code this small, I don't think readability is as
important of an element. Personally I would do `((a) => a.name)`, which is
short and, most importantly, very explicit about what it is doing. If you
know what a function is and you know what a property is, you know what this
c
It's worth noting that engine262 doesn't use the RunJobs implementation it
has, it uses a separate entrypoint in api.mjs. There is some work going on
to get rid of RunJobs entirely, as no implementations actually use it (
https://github.com/tc39/ecma262/pull/735)
On Sat, Aug 17, 2019, 14:29 Cyril
> Sure thing, engines might infer returned values in some hot code and skip
the microtask dance once it's sure some callback might return values that
are not promises, but what if developers could give hints about this
possibility?
Engines can't do this, because it would change the observable orde
Related discussion https://github.com/tc39/ecma262/issues/1399
On Thu, Nov 7, 2019 at 8:46 AM Alex Kodat wrote:
> Just curious. Is there a reason template literals are not allowed as
> property names in object literals? I can do:
>
>let obj = {'foo bar': 1};
>
> and
>
>let obj = {"foo ba
> From: Jordan Harband
> Sent: Thursday, November 7, 2019 2:44 PM
> To: Alex Kodat
> Cc: Gus Caplan ; es-discuss@mozilla.org
> Subject: Re: Template literal property names in object literals
>
> It would create the ambiguity that "every property name not in brac
Check this out:
https://github.com/tc39/proposal-explicit-resource-management
On Fri, Apr 17, 2020 at 2:44 PM Ben Manashirov wrote:
> Hello,
>
> It's easy to leak data in javascript because you need to call free(), or
> destroy() for various objects, for example when interfacing with OpenGL,
> e
I would either tweak the framework:
describe('thing', () => {
provide(() => new Thing());
it('does one thing', (thing) => {
thing.oneThing();
});
it('does other things', (thing) => {
thing.otherThings();
});
});
or just explicitly do `const thing = new Thing()` in each test.
On
Modules in the spec are cached by specifier by modules that import them.
Modules in major implementations are additionally cached for the entire
realm by absolute URLs. I would say that for actual code (functions and
classes and whatnot) leaks aren't really a problem. Even if you import a
ton of le
17 matches
Mail list logo