PWAs and events aren't part of the JS language; see
https://html.spec.whatwg.org
On Tue, Mar 30, 2021 at 5:39 AM Adam Eisenreich wrote:
> I think that PWA should have the ability to override the default
> beforeunloadEvent message.
>
> Since returning string is already deprecated and removed
Hi everyone,
We were informed last year that Mozilla would be sunsetting it's mailing
list server at some point in the future. We were not sure of the exact
date, but to account for this, the TC39 chairs created
https://es.discourse.group. Quite a bit of discussion has migrated there,
but there
I think that PWA should have the ability to override the default
beforeunloadEvent message.
Since returning string is already deprecated and removed from all browsers,
it would be safe to change how the returned value is handeled.
All proposed changes should only apply to installed PWAs!
Hello,
On 2021-03-16 10:43, Logan Smyth writes:
>> as this code does not seem to take an argument.
>
> The resumption state set by `GeneratorStart` does not take an argument
> because there is no way to access the first resumption value in a
> generator, though there is the `function.sent`
> as this code does not seem to take an argument.
The resumption state set by `GeneratorStart` does not take an argument
because there is no way to access the first resumption value in a
generator, though there is the `function.sent` proposal to allow that:
Hello,
I am trying to understand how the resuming of execution contexts work.
For instance, step 9 of
https://tc39.es/ecma262/2021/#sec-generatorresume says "Resume the
suspended evaluation of genContext using NormalCompletion(value) as the
result of the operation that suspended it." I can see
in PHP &$ref means by reference ... and in C is about the address ... I
understand your proposal, but I see few gotchas in it:
```js
let { x: ref x } = obj;
```
my proposal is:
```js
let {} = obj;
```
less typing, less eyes crawling, it's about describing the intent to
change, or address,
This was mentioned up-thread, but I wrote up this proposal several years ago
(https://github.com/rbuckton/proposal-refs) and am still considering bringing
it to committee at some point. However, there are a larger set of cross-cutting
concerns for refs in the context of a proposal like
> How will you prevent the passing of the object down the pipe?
```js
const downThePipe = ({}) => {
// you can read source
source;
// you can set source
source = 'blah';
// you can't know where source comes from
// but you could propagate that reference further
evenFurtherDown({,
Or maybe it would be
```js
theFunction(obj., obj.);
```
to explicitly pass the particular properties, and would account for
nested properties too:
```js
theFunction(obj.foo., obj.lorem.);
```
#!/JoePea
On Wed, Mar 3, 2021 at 6:29 PM #!/JoePea wrote:
>
> I think it is a good idea, but maybe
I think it is a good idea, but maybe we need to think about what the
final syntax would be. About segregation, if the library changes the
signature, then they'll have the whole source object, right? Maybe for
the mentioned security the user would need to opt in:
```js
theFunction(, );
```
would
> that's basically the entirety of the syntax sugar proposals since ES2015,
right?
Definitely no, but talking about the syntax additions since ES2015, they
are in one or more of the categories below:
- avoid known footguns in the language (arrow functions and lexical this,
classes and prototype,
to expand further: you *could* access such reference via `arguments[0]`,
but *that* won't be possible with arrow functions, as example, so that
`({}, maybe) => { if (maybe) reactive = true; }` is another
pattern that doesn't need the whole object around, or to be propagated,
when you can pass it
> the proposal is just a debatable syntax sugar for something we already
can do
that's basically the entirety of the syntax sugar proposals since ES2015,
right? also proxy and globalThis are *really* unrelated to this, imho,
while leaking objects all over down the pipe is my major concern,
> ```js
> function stuff(source, extra) {
> const {value, method} = source;
>
> if (condition)
> method.call(source);
>
> if (value === extra)
> source.value = 'no more';
> }
> ```
I mean, in this case you can skip destructuring altogether, having a one
way and way only of value
The way I see it: it's just a convention/shortcut to have the destructured
object around.
```js
function augment({}, testCase) {
if (/thing/.test(testCase))
value += testCase;
}
let any = {value: ''};
augment(any, 'thing');
```
The magical behavior goal is to define side effects when
I don't know, the by reference destructuring seems a bit too much magical,
a scoped variable that sets to a property to a object just sounds like the
old `with` statement but reduced and more explicit, given is just a sugar
and currently the problem is not a great of a pain point I would be very
I would like to see this happen, though I'd like to see it integrated with
reified refs. (I know there's a proposal laying around somewhere drafted up
by a current or former TC39 person, but I can't find it.)
-
Claudia Meadows
cont...@isiahmeadows.com
On Tue, Mar 2, 2021 at 11:05 AM Andrea
Another one (cit. DJ Khaled)
has "by reference" ever been considered as "yet another JS syntax" ???
let object = {value: 1};
let {} = object;
value = 2;
object.value; // 2
allowed everywhere destructuring is possible, throwing for frozen
properties ... is this just meh? .. .'cause I think,
Hello!
Has any equivalent feature for the nullish coalescing ?? and optional
chaining ?. operators been proposed to paper over the deficiencies of
the destructuring syntax with regards to null values?
If not, I think one should be proposed. For the entire right side of
the binding, an equivalent
Hello there
this is going to be quick: how about using the bind operator *at least*
for destructuring?
```js
// today
function util(ref) {
if (ref.prop === 1)
ref.method(2);
}
// tomorrow?
function util({prop, ::method}) {
if (prop === 1)
method(2);
}
```
Such shortcut would
For Node.js we implemented this as an alternative to the current setTimeout:
const { setTimeout } = require('timers/promises')
// Or
import { setTimeout } from 'timers/promises'
Then...
await setTimeout(500)
It works very well and is straightforward to implement on the browser-side.
On Sun,
Yeah, that's the problem, no totally robust solution, often resorting to
`any`, often the need to take some tricks from several sources, etc.
That's why I'm asking about a truly standard solution, thought during the
TC features proposal.
Imho, if a feature can't be fully described, it must be
This SO answer provides a typing for Object.assign that appears to
basically do the right thing: https://stackoverflow.com/a/51603499 -- but
none of the above libraries use this kind of solution, which leads me to
think it might not be totally robust
On Wed, Nov 11, 2020 at 1:27 PM Jordan Harband
Of course there's a way - it's just that TS's built-in types don't
consistently go the extra mile, and often resort to `any`. See
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/5344bfc80508c53a23dae37b860fb0c905ff7b24/types/object-assign/index.d.ts,
or
Interesting, on my system I consistently see Set iteration is faster
(I replayed it many times). I'm in Chrome 85, Linux. This might be
temporary.
> `new Set(Object.keys(obj))`
That creates two objects and an iteration (will the engine optimize
that away?), while `Object.keySet` (or similar)
>We could wirte a simpler parser just for the imports subset
IMHO code on client and server isn't the root problem. I've written a few
versions and the biggest issue I had was how to distinguish an `import`
request/fetch from any other. There is nothing in the request metadata to let
you know
We could wirte a simpler parser just for the imports subset, given the
simpler isolated grammar I don't think is that hard with parser
combinators. Maybe it's a cool idea for a npm library that just points out
the dependencies of a single file and then recursively scan the rest. From
that is just
On Thu, Oct 22, 2020 at 2:23 PM #!/JoePea wrote:
> > It's caused me some headaches especially when dealing with
> inheritance/extends and in workers.
>
> Like, extending from a `Module` object?
>
> > Maybe someday we'll have a `modules` collection we can interrogate.
>
> That may be nice, to
> It's caused me some headaches especially when dealing with
> inheritance/extends and in workers.
Like, extending from a `Module` object?
> Maybe someday we'll have a `modules` collection we can interrogate.
That may be nice, to query which modules have already been imported, etc.
It would
`new Set(Object.keys(obj))` seems pretty straightforward - I doubt it's
worth adding something to the language just to make that shorter.
Separately, if you're looking for a deduped O(1) lookup of key presence,
you already have _an object_ - `Object.prototype.hasOwnProperty.call(obj,
key)`.
On
Right, it's basically just doing what an import aware server might do and the
type-tree is a hierarchal version of the scope imports. The rest is just extra
stuff. Probably the biggest difference though is that it lets me isolate
prototypes. From what I gather it seems that import stores a live
Other than the fact that Object.keys existed really before Sets, you are
comparing apples and oranges here in your benchmarks.
the include method has to scan the array in order to find elements, but
sets are objects which are just hash tables.
Also you typically don't get the keys array to check
I think that we can't add a new parameter on `Object.keys`, because it
could be a break change (and it will be a little bad to read).
We could add a new method on `Object`, like `Object.keysSet`, but I don't
know how important it is.
On Sun, 18 Oct 2020 at 04:26, #!/JoePea wrote:
> Well that
I think it's a good idea that would make things more efficient. +1
*#!/*JoePea
On Thu, Sep 17, 2020 at 12:57 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I'm not sure I'm following, but I'm not here to find solutions, I already
> have solutions, I'm here to propose a new
That's neat, but it seems like the same work that a server would have
to do with actual ES Module imports, right? And the "type tree"
equivalent is the modules that the JS engine stores as a map from
import identifier to module scope instance. It seems that in the end,
the `PUSH` approach should
That would be interesting indeed. Encouraging documentation is great I think.
#!/JoePea
On Sat, Oct 17, 2020 at 3:38 AM Michaël Rouges wrote:
>
> Yeah, I prefer the JSDoc solution too for the same reasons... but JSDoc is
> really slow to evolve,
> always several years behind the standard, a lot
Well that makes sense! Would it be worth adding an option like
`Object.keys(obj, true)` to return a set? Or perhaps
`Object.keySet(obj)`?
#!/JoePea
On Fri, Oct 16, 2020 at 11:54 PM Jordan Harband wrote:
>
> Because Object.keys was standardized in 2009, 6 years before Set existed.
>
> On Fri, Oct
I think some form of bundling will always be necessary. I use classes and took
a name-spaced and typed approach to modules and classes, putting each class in
its own module in a file hierarchy (namespace). This is an enterprise level LOB
application with dozens of classes. Many classes are used
Yeah, I prefer the JSDoc solution too for the same reasons... but JSDoc is
really slow to evolve,
always several years behind the standard, a lot of solutions to describe
our code are more relevant
to **tricks**, generally found on the JSDoc issues, than something formal.
The coverage isn't the
Because Object.keys was standardized in 2009, 6 years before Set existed.
On Fri, Oct 16, 2020 at 6:51 PM #!/JoePea wrote:
> Sets are faster, even for tiny lists of four items. See the perf tests
> (tested in Chrome):
>
> https://twitter.com/trusktr/status/1315848017535098880
>
>
es-dev-server by open-wc seems to be import-aware.
https://open-wc.org/developing/es-dev-server.html
#!/JoePea
On Fri, Oct 16, 2020 at 6:40 PM #!/JoePea wrote:
>
> So in practice, bundling is still a thing because there isn't an
> import-aware server that has been released that proves to be
Sets are faster, even for tiny lists of four items. See the perf tests
(tested in Chrome):
https://twitter.com/trusktr/status/1315848017535098880
https://twitter.com/trusktr/status/1317281652540731392
#!/JoePea
___
es-discuss mailing list
So in practice, bundling is still a thing because there isn't an
import-aware server that has been released that proves to be better
than bundling? Or perhaps it's too much overhead to set up a server,
so people just bundle?
#!/JoePea
On Wed, Oct 14, 2020 at 2:45 PM Randy Buchholz wrote:
>
>
Would official syntax be worth it (JSDoc being officially standardized)?
Maybe it's a matter of time: Perhaps now that JSDoc is useful for type
checking (thanks to TypeScript and its ability to type check plain
JavaScript that is annotated with JSDoc) it may be closer to reality.
I prefer JSDoc
I've been doing some work around module loading/importing recently, writing
some "import awareness" into the server request pipeline. I'm also doing things
on the client side, but I'm not set up to build a browser so I'm substituting a
DI based `injection` approach for the `import` operation.
> Sorry but my question isn't about providing a tool to generate our
documentations but to have a standard syntax to describe our code
(signatures). ;)
not standard-practice, but my style is to have documentation of functions
inside the function (rather than above it).
simplifies doc-generation
Sorry but my question isn't about providing a tool to generate our
documentations but to have a standard syntax to describe our code
(signatures). ;)
Michaël Rouges - https://github.com/Lcfvs - @Lcfvs
Le mar. 13 oct. 2020 à 01:29, Jordan Harband a écrit :
> Hopefully (imo) people are
I'd find it more readable to allow an assignment operator, with the
semantic "do this transformation, using the passed value as the previous
value"
```
function (x ??= 123) {} // If passed null or undefined, x = 123
function (x &&= 123) {} // If passed a truthy value, x = 123
function (x += 123)
What about allowing any expression then?
x || 4
x/4
x + 4
x + w //maybe allow only "previous" parameter values as scope
x + a //SyntaxError: 'a' undefined in parameters scope
On Tue, 13 Oct 2020 at 14:39, Michael Luder-Rosefield <
rosyatran...@gmail.com> wrote:
> I know I am not the only one
I know I am not the only one who has had several perfectly good use-cases
for default values disallowed, because the value coming in was `null`, not
`undefined`.
I cannot be the only one who has let bugs slip in because of failing to
consider this case.
So, if we can find a non-confusing and
Hopefully (imo) people are hand-writing more docs now, rather than relying
on autogenerated prose.
On Mon, Oct 12, 2020 at 1:23 PM #!/JoePea wrote:
> Why not? People are generating less docs now? That doesn't sound good!
>
> #!/JoePea
>
> On Mon, Aug 17, 2020 at 4:15 PM Isiah Meadows
> wrote:
Gotcha. So basically that tells the consumer "No, you can't use
Proxies". What I want to tell them is "Go ahead, use Proxies to your
heart's content", but I don't want to tell them to write all the
overly-complicated code required for their Proxies to work properly as
soon as I introduce a single
Sure, but I'm first curious about classes because in my example, the
code is all defined _inside_ a class definition's lexical scope, where
private fields (or keys) are _currently_ defined to exist, so it seems
like an approach we can currently take.
Private fields on objects without classes
Why not? People are generating less docs now? That doesn't sound good!
#!/JoePea
On Mon, Aug 17, 2020 at 4:15 PM Isiah Meadows wrote:
>
> JSDoc is not dead (far from it), people just don't frequently use
> automated docs generation tooling in the JS community. Most the actual
> use JSDoc
Right, exactly. So naively sending all dependencies wastefully is just
the first step.
> Afaik the more promising path are prefetch hints on the client. E.g. the
client (or initial HTML payload) knows the dependency tree, adds tags
for preloading the required modules, and then the browser can
> If I understand HTTP/2 correctly, this requires more than a server
> that simply has HTTP push, it requires a server that understands how
> to read ES modules and enumerate their dependencies.
Not only that: The server also has to "know" which modules are already
cached by the client (including
I'm asking about a server that, upon request of a `.js` file, knows
how to enumerate the dependency tree based on that file, _then_ HTTP
pushes all the modules at once.
So basically, from the code
```html
Why isn't it a thing yet?
- http://www.petecorey.com/blog/2016/07/17/meteors-nested-import-controversy/
- https://github.com/benjamn/reify/blob/master/WHY_NEST_IMPORTS.md
At runtime they'd be similar to `await`ing an `import` statement.
Maybe a requirement should be that nested
On Sat, Oct 10, 2020 at 5:19 PM #!/JoePea wrote:
> It's 5 years later, but still no (obvious) sign of HTTP/2 servers
> specialized in ES Module push.
>
What does it mean to specialize in module push? How can modules be pushed
without the browser requesting them? Is it a server that reads the
It's 5 years later, but still no (obvious) sign of HTTP/2 servers
specialized in ES Module push.
Do any exist? Anyone have a list? I'm especially interested in the
self-hostable servers, but also curious about solutions where we may
publish modules to.
The non-self-hosted solutions may be
By the way, the VS Code plugin I use is [Comment tagged
templates](https://marketplace.visualstudio.com/items?itemName=bierner.comment-tagged-templates).
Works great, allows any extension in the comment, and it will
highlight as long as you have that syntax installed separately.
I got tired of
I mean, it would be only a parse time cost if the identity tag is used like
```js
String.tag`...anything...`
```
assuming it is not monkey-patchable (readonly). But maybe if it is
patchable then all bets are off, and it has a runtime cost.
#!/JoePea
On Thu, Sep 24, 2020 at 2:22 PM #!/JoePea
Perhaps a built-in identity tag would be only a parse-time performance cost.
#!/JoePea
On Thu, Sep 24, 2020 at 2:21 PM #!/JoePea wrote:
>
> I don't know what you mean about the raw stuff, but using `/*css*/`
> works perfectly fine in VS Code with a plugin. There's no reason
> intellisense can't
I don't know what you mean about the raw stuff, but using `/*css*/`
works perfectly fine in VS Code with a plugin. There's no reason
intellisense can't work inside the commented string. If you meant
about completing the `css` part, if you accidentally write `/*ccs*/`
then the colors won't look
Fortunately my analysis was wrong, all systems are go!
The revised serialization deals with pathological UTF which RFC 8785 anyway
outlaws.
Anders
On 2020-09-21 05:56, Anders Rundgren wrote:
Hi ES-lovers,
I have co-authored a JSON canonicalization scheme, recently published as an
RFC:
Hi ES-lovers,
I have co-authored a JSON canonicalization scheme, recently published as an
RFC: https://www.rfc-editor.org/rfc/rfc8785.html
The work started with ES V6 as foundation since it made things really easy.
Serialization of quoted strings where taken "as is" from:
I'm not sure I'm following, but I'm not here to find solutions, I already
have solutions, I'm here to propose a new `Function.prototype.bindContext`
method that doesn't require any user-land discussion/prototype pollution.
Thanks.
On Thu, Sep 17, 2020 at 9:25 PM Adam Eisenreich wrote:
> This
This should able to be done via two nested WakMap,
First level would be the function and the second the context or vice versa.
This should be able to give you the same bound function while both are
avaible, but should clear itself once the reference to function/context is
lost.
--
I've found myself (once again) polluting the `Function.prototype` with a
lazy method that, once invoked, grants that the returned bound function is
always the same, per context.
# Use Case
It's still a common footgun to add events either via `context.method` or
via
I was aware of TypeScript, but with Enum/FlagsEnum you can still do: ```o.collisionType = ‘circle’;``` ... As long as there’s this code in O: ```set collisionType(v) { this._type = CollisionType(v); }``` When some f() takes a CollisionType, it takes any argument and calls CollisionType(v). A
For what it's worth, TypeScript has Enums built-in and I find myself using
string literal types instead:
```typescript
type CollisionType = 'CIRCLE' | 'CUBIC_BEZIER_CURVE' | 'RIGID_BODY';
function handleCollision(type: CollisionType) {
if (type === 'CIRCLE') {
// ...
} else if (type ===
The com.siteblade.util package contains an approximation of this in ECMAScript, with no difference, except the valueOf() method (which returns String for working with equality), so it ends up with an additional getter ‘number’. https://www.npmjs.com/package/com.siteblade.util You can use either
The com.siteblade.util package contains an approximation of this in
ECMAScript.
https://www.npmjs.com/package/com.siteblade.util
You can use either FlagsEnum or Enum.
import { Enum } from 'com.siteblade.util';
const CollisionType = Enum('CollisionType', [
['CIRCLE'],
Flags enums would be primitive classes with constants (_name_:String,
_value_:Number). It'd be very, very efficient.
Of course it's easy to use POJOs (`{}`) instead of numeric values, but this
feature would only provide performance advantages.
The following program implies:
- `String(E.FNX) ==
Sorry, I should be a few more explicit about the needs, I'll try to fix it.
(Sorry If my english isn't perfect, it isn't my native language)
Ihmo, the developers needs a strong/robust/uniform way to describe their
code, using static types comments and how they are using the language
features,
JSDoc is not dead (far from it), people just don't frequently use
automated docs generation tooling in the JS community. Most the actual
use JSDoc provides nowadays is editor autocomplete hints and
integrating with TypeScript (in cases where changing the extension
isn't possible for whatever
It’s close, but not quite the same, from a cursory read. Thanks for sharing
though.
To respond to the original post, I don’t think something rigidly formal would
work out given how many wildly different opinions are out there - thinking out
loud, but perhaps something underlying similar to
> This feels like rich territory for a blog post, if someone feels
qualified? Specifically, just running the typescript tool chain for jsdoc
annotations, which are excellent for all the reasons mentioned above
(comments only, vanilla js etc).
Does this count?
This feels like rich territory for a blog post, if someone feels qualified?
Specifically, just running the typescript tool chain for jsdoc annotations,
which are excellent for all the reasons mentioned above (comments only, vanilla
js etc).
> On 17. Aug 2020, at 19:35, Andrea Giammarchi
>
Sorry, new link:
https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html
On Mon, Aug 17, 2020 at 8:34 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> TS supports JSDocs already
>
>
TS supports JSDocs already
https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#supported-jsdoc
On Mon, Aug 17, 2020 at 8:31 PM Bergi wrote:
> Hi,
>
> > They don't want to add TS to their stack.
>
> Then what else would they want to add to their stack? Notice one
Hi,
> They don't want to add TS to their stack.
Then what else would they want to add to their stack? Notice one doesn't
necessarily need the TypeScript Compiler to add TypeScript- or Flow-like
type annotations and remove them in a build step - Babel for example
could do that just fine as well.
Hi all,
Since JSDoc seems cerebrally dead, why the TC39 doesn't make a real
documentation standard, evolving with the langage?
Actually, a part of the JS community are exiling to TS to type anything
and the rest are just despited by the very outdated version of JSDoc but
don't want to add TS to
Why stop at class definitions?
e.g.
```js
let obj;
{
let local = 0;
obj = {
get local() {
return local;
}
}
}
```
becomes
```js
const obj = {
#local: 0,
get local() {
return this.#local;
}
}
```
On Fri, Aug 7, 2020 at 3:33 PM #!/JoePea wrote:
> Not sure if the
Not sure if the following is exactly how we'd want it to be, but it
would be useful:
```js
class Foo {
// calculatedValue is intended to have read-only properties
calculatedValue = {
#x: 0,
get x() { return this.#x },
#y: 0,
get y() { return this.#y },
#z: 0,
get z() {
Maybe a convention between hosts to prefix an import with an integrity
check?
``` js
import foo from 'sha1sum:ef70d15a0700d2108e0df27dde750f5c682b4697!./foo.js';
```
It looks kinda of dirty, but the specification allows it (aside from the
colon character that is forbidden right now)
This types of
Hi,
> The problem with inlining the integrity into every import site is that this
> is naturally incompatible with import maps.
I don't see a problem with that. When using import maps, you should be
able to specifiy the integrity check in the import map, not needing it
in the module itself.
When
The problem with inlining the integrity into every import site is that this
is naturally incompatible with import maps.
On Sat, 1 Aug 2020 at 08:57, Jordan Harband wrote:
> That seems like something that could possibly be achieved via
> https://github.com/tc39/proposal-import-assertions
>
> On
That seems like something that could possibly be achieved via
https://github.com/tc39/proposal-import-assertions
On Sat, Aug 1, 2020 at 1:15 AM Michaël Rouges
wrote:
> Hi all,
>
> As proposed a year ago on an old repository (thanks to ljharb, noticed me
> that fact), on the browser side, the
Hi all,
As proposed a year ago on an old repository (thanks to ljharb, noticed me
that fact), on the browser side, the integrity check should be controllable
**for each imported module**. Actually, it's just impossible to do it
without bundling.
There is no "interpolation values array"; a tag function receives a single
frozen array of static template contents (unique per call site) and a
distinct argument for each substitution value. Source code can collect them
*into* an array by use of ... "rest" syntax, but every evaluation of that
oh oops, i meant `if (o !== this)` not `if (o.foo !== this)` :-)
On Mon, Jul 27, 2020 at 3:06 PM #!/JoePea wrote:
> > `o.foo(); // works`
>
> I think there is something missing from that example as that line
> throws before it can get to the `new Proxy` line.
>
> #!/JoePea
>
> On Wed, Jul 15,
> `o.foo(); // works`
I think there is something missing from that example as that line
throws before it can get to the `new Proxy` line.
#!/JoePea
On Wed, Jul 15, 2020 at 10:47 PM Jordan Harband wrote:
>
> So can:
> ```jsx
> const o = { foo() { if (o.foo !== this) { throw 'detected'; } } };
>
> to start with, assuming the same `arguments` object is passed twice to two
> different invokes of a callback, would break down to ES3 and lower.
I know, that's what I mentioned (it is historical, will never be the
same object). :)
> interpolated values you are passing around are always
there is some fundamental misconception of the ECMAScript standard in these
examples ... to start with, assuming the same `arguments` object is passed
twice to two different invokes of a callback, would break down to ES3 and
lower.
Secondly, interpolated values you are passing around are always
The following doesn't work either, and obviously it probably will
never change because it is historical:
```js
argsArrays = []
function html() {
argsArrays.push(arguments)
}
let n = 0
let n2 = 0
function render() { return html`1st: ${n++}, 2nd: ${n2++}.` }
render()
render()
What I mean is,
We can currently do this (try it in console):
```js
arrays = []
function html(parts) { arrays.push(parts) }
let n = 0
let n2 = 0
function render() { return html`1st: ${n++}, 2nd: ${n2++}.` }
render()
render()
console.log(arrays[0] === arrays[1]) // true! <---
The spec and implementation are exactly defined like this - v8 directly
provides HostResolveImportedModule exactly to the spec, returning a module
object for a given specifier and module parent. By default in v8 modules
are GC'able objects... they don't implement registries currently. There's
just
For the web, one could lock it down with CORS-like restrictions, too,
so a script from one domain isn't allowed to modify cached entries
from another domain. It's not insurmountable.
This is part of why I feel the invariant should be removed and the
spec should just internally resolve static
1 - 100 of 41128 matches
Mail list logo
