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
gt; >> > html += "function " + name + " " + signature.trim()
>> + "\n";
>> >> > html += "\n" + comment + "\n\n";
>> >> > html += "\n";
>> >> >
`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
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
>
>
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:
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
ea
>
> On Wed, Jul 15, 2020 at 10:47 PM Jordan Harband wrote:
> >
> > So can:
> > ```jsx
> > const o = { foo() { if (o.foo !== this) { throw 'detected'; } } };
> > o.foo(); // works
> > new Proxy(o, {}).foo(); // throws
> > ```
> >
>
So can:
```jsx
const o = { foo() { if (o.foo !== this) { throw 'detected'; } } };
o.foo(); // works
new Proxy(o, {}).foo(); // throws
```
(as would a class that used a closed-over WeakMap for each "private field")
Private fields do not introduce any new hazards here.
On Tue, Jul 14, 2020 at
You already do have that right; you can use any Promise implementation you
choose, or none at all. You do *not*, however, typically have the "right"
to alter what syntax does, and `async`/`await` explicitly chose that
philosophy.
On Tue, May 5, 2020 at 11:37 PM medikoo
wrote:
> J
Anything "more efficient" would likely not be spec compliant, which would
break code relying on those guarantees. Overriding any builtin is a bad
practice for well over a decade, and I'm not sure why doing so would be
desirable. "Fast" doesn't matter if correctness is not assured.
On Tue, May 5,
I'm confused about that as well; there were a spate of CVEs about it a year
or two ago (2 or 3 of my libraries were "affected"), but just like the
minimist/mkdirp ones, they were only actually vulnerabilities for a
minority of the use cases. Have there been any recent vulnerabilities
you're aware
See https://github.com/tc39/proposal-optional-chaining/issues/18
On Thu, Apr 30, 2020 at 1:08 PM #!/JoePea wrote:
> I was hoping to avoid things like
>
> ```js
> const baz = this.foo?.bar?.baz
> if (baz) baz.lorem = 123
> ```
>
> #!/JoePea
>
> On Thu, Apr 30, 2020 at 1:04 PM #!/JoePea wrote:
>
The iteration protocol has a boolean data property `.done` - I don't know
if anyone ever suggested some kind of `isDone()` method for that, and I
think the iteration protocol sets a precedent of the "tag" on the object
being a primitive.
On Fri, Apr 17, 2020 at 7:25 PM Felipe Gasper
wrote:
>
Are you familiar with https://github.com/tc39/proposal-logical-assignment/ ?
On Mon, Apr 13, 2020 at 2:17 AM Sultan wrote:
> The following would assign to the address foo in obj if and only if it has
> not already been assigned.
>
> var obj = {}
> var foo = Math.random()
> obj[foo] ?= 1
>
> The
It does pass through the fulfillment status - but it does that by adding
both an onFulfilled and an onRejected handler, so it does affect the
"unhandled rejection" hook.
On Sat, Mar 28, 2020 at 7:23 PM Felipe Gasper
wrote:
> Hi Logan,
>
> Thank you .. that makes sense. I’m not sure why now but
@kdex (sorry i missed this; your message was in my spam folder) if you find
a way that Annex E is non-exhaustive, please file an issue on the spec - I
would like it to be exhaustive.
On Mon, Feb 3, 2020 at 11:16 AM Naveen Chawla wrote:
> Thanks! Although I think it is a value judgement about
> somehow.
>
> On Sat, Feb 15, 2020 at 10:05 AM Jordan Harband wrote:
>
>> Since object spread already ignores nullish values, a syntax change would
>> only be needed for array spread. Then, the two kinds of spread would
>> support different syntactic features, which seems incons
Since object spread already ignores nullish values, a syntax change would
only be needed for array spread. Then, the two kinds of spread would
support different syntactic features, which seems inconsistent.
On Sat, Feb 15, 2020 at 7:56 AM Beknar Askarov
wrote:
> Thank you, everyone, for
Wouldn't the solution be, don't use `import * as`, but instead, explicitly
import and re-export what you want?
On Thu, Feb 13, 2020 at 8:02 PM Ben Wiley wrote:
> Apologies if this has already been talked about at length at some point. I
> was unable to find much in the way of relevant
fineProperties(
> base,
> mixins.reduce(
> (descriptors, mixin) => assign(
> descriptors,
> getOwnPropertyDescriptors(mixin)
> ),
> {}
> )
> );
> ```
>
> On Thu, Feb 13, 2020 at 6:51 PM Jordan Harband wrote:
>
>> `Ob
`Object.defineProperties(target, Object.getOwnPropertyDescriptors(source))`?
On Thu, Feb 13, 2020 at 2:24 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Both `Object.assign` and `{...extend}` suffer a tiny gotcha: properties
> are never assigned, neither retrieved, as accessors,
ome better primitive, as in `const Shape =
> Object.defineShape(...)` and `Object.createShape(Shape)` or similar.
>
> On Sun, Feb 9, 2020 at 10:01 PM Jordan Harband wrote:
>
>> That already exists - `Array.from({ length: 4 }, () => whatever)` - I
>> assume that the hope is to have
That already exists - `Array.from({ length: 4 }, () => whatever)` - I
assume that the hope is to have an array where it is *impossible* for it to
have the wrong "kind" of data, and a userland factory function wouldn't
provide that.
On Sun, Feb 9, 2020 at 10:39 AM kai zhu wrote:
> > It's a bit
I would not be interested in adding any more mutating methods to
Array.prototype, ever. I'd suggest using `.filter` for this.
On Fri, Feb 7, 2020 at 5:29 AM manuelbarzi wrote:
> many things that already provide array could be polyfilled, and probably
> many were polyfills before. it's not about
the "type" in Typed Arrays refers to the bit size in memory; being able to
pass an arbitrary value seems like it would require implementations to
calculate the precise (not just the maximum) memory size a single item
requires.
On Fri, Feb 7, 2020 at 6:33 AM Andrea Giammarchi <
If we have `await.all`, what about `await.race`, `await.allSettled`,
`await.any`?
On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom
wrote:
> To simplify the problem of working with promises in parallel, I
> propose this new syntax:
>
> ```javascript
> async function initialize() {
> let foo, bar,
Michaël Rouges
wrote:
> For example, to easily sort the values, compared with another list, using
> only one iteration.
>
> Le mar. 12 nov. 2019 à 07:42, Jordan Harband a écrit :
>
>> I'd assume it's because sort predates ES5, when the thisArg was added;
>> and
I'd assume it's because sort predates ES5, when the thisArg was added; and
also because a well-behaved comparator only operates based on `a` and `b` -
why would you need a receiver?
On Mon, Nov 11, 2019 at 7:34 PM Michaël Rouges
wrote:
> Hi all,
>
> Is there a reason to not have a `thisArg `
wouldn't seem to present daunting implementation issues.
> But maybe this last assertion is incorrect and ambiguities would arise or
> implementation would be a nightmare?
>
> Thanks
>
> --
> Alex Kodat
> Senior Product Architect
> Rocket Software
> t: +1 781 684 229
Anything dynamic - computed - should be in brackets, since that's what that
indicates.
Thus, template literals with substitutions must require brackets.
Based on sentiments like
https://github.com/tc39/ecma262/issues/1399#issuecomment-452910799, either
all template literals or none should be
for this specific reason, as it's easy to write for all
> types of people.
>
> Thank you all,
> --
> *From:* es-discuss on behalf of kai zhu <
> kaizhu...@gmail.com>
> *Sent:* Saturday, November 2, 2019 8:06:50 PM
> *To:* Jordan Harband
&g
My preference would be to make them required in the places they're
currently optional :-)
Optional curly braces have led to many bugs, not just in JS (the "goto
fail" SSL bug, for example) - why is this risk worth making it easier to
write code on a whiteboard, where it doesn't need to be valid
The current API accepts an *iterable*, which means any object that has
`Symbol.iterator`, such as an array or a Set.
Throwing when it receives a non-iterable object is an important tool to
catch bugs. If Promise.all was made to accept a non-iterable object as
well, I suspect many bugs would go
This question is more appropriate for the proposal repo, in which a very
lengthy naming document will hopefully answer all of your questions:
https://github.com/tc39/proposal-global/blob/master/NAMING.md
Please address all further comments or replies on this topic to the
proposal repo. Thanks!
By default, the behavior would have to remain the same, or else it would
break the web.
See https://esdiscuss.org/topic/object-id-hash-etc for more on hash codes.
On Sun, Sep 8, 2019 at 4:36 AM Tadas Lapė wrote:
> The problem
>
> Javascript allows to index objects not only with strings,
There's already `.codePointAt`, and `[...str].length`.
The thing that's really needed more than code points is grapheme clusters;
see https://esdiscuss.org/topic/working-with-grapheme-clusters
On Sun, Sep 8, 2019 at 5:01 AM Dimitrian Nine
wrote:
> Maybe i don't know something, but want to
`var itself = 3;` means that your choice of keyword wouldn't be an option;
you'd be limited to something that was currently a syntax error.
On Fri, Sep 6, 2019 at 2:53 AM Cyril Auburtin
wrote:
> also optional-chaining will help
> ```js
> return {
> ...state,
> child: {
>
Syntactically marking, in a chain, what you'd like the final value of the
chain to be, seems interesting - forcing optionality into it seems
unnecessary, though, if such a syntactic marker could be attached to all
forms of property access.
Something like: `a.b>.c.d` or `a?.b>?.c?.d` or
Since you can do this now with:
```js
[
1,
...(condition ? [2, 3] : []),
3,
]
```
and object spreading already handles this for you, is extra syntax really
needed?
On Thu, Aug 22, 2019 at 6:52 PM Scott Rudiger
wrote:
> I like it; code seems cleaner to me with its use. However, since the
Can you elaborate a bit more on how this is a *common* case in the wider
ecosystem?
On Fri, Aug 16, 2019 at 5:29 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> early reply "which otehr cases"? this is just an example:
>
> [2019, 08, 16, 14, 28, 30].map(i => i < 10 ? ('0' + i)
I believe every array iteration method that takes a callback, except for
reduce and reduceRight, take an optional receiver as the last argument (the
`this` value), so they can't be meaningfully/ergonomically extended.
On Thu, Aug 15, 2019 at 3:00 PM Andrea Giammarchi <
Static functions don't have the same risk as prototype functions;
`Math.mod` would make sense to add.
One suggestion, though, would be to try to add the API method first, and
look at usage for awhile before trying to add the syntax.
On Thu, Aug 15, 2019 at 10:12 AM Andrea Giammarchi <
No, that's not accurate - every `.then` always executes on a future tick,
never synchronously.
On Sat, Jul 27, 2019 at 11:11 PM Ranando King wrote:
> Isn't it always the case that `Promise.resolve()` returns an immediately
> resolved Promise? That means that the `.then` clause would get
When I run this in a node repl, that's exactly what happens - perhaps your
simplified example has simplified out the bug?
On Sat, Jul 27, 2019 at 6:57 PM #!/JoePea wrote:
> I feel like I'm going crazy, but I have a class hierarchy, and one of
> the constructors in the hierarchy defers some
t; You can see examples of this on comp.lang.javascript, and through a search
> engine by looking for "return document.all" or "return document.layers".
> There are also some legacy books showing the practice.
>
> /Michael
>
>
> -Original Message-
&g
e able to supplant `instanceof`
> without losing any of its reliability. Just a thought...
>
> On Sat, Jul 27, 2019 at 3:57 PM Jordan Harband wrote:
>
>> With something that while unintuitive in one case, is eternally robust
>> and reliable.
>>
>> If you want exte
ogonal, where does that leave you?
>
>
>
> [1] <https://twitter.com/BrendanEich/status/798317702775324672>
>
>
>
> *From:* Jordan Harband
> *Sent:* Saturday, July 27, 2019 3:00 PM
> *To:* Michael Haufe
> *Cc:* ViliusCreator ; es-discuss@mozilla.org
> *S
See https://github.com/tc39/proposal-iterator-helpers
On Sat, Jul 27, 2019 at 1:45 PM Artem Kobzar wrote:
> The proposal based on really worst thing in JavaScript Arrays.
>
> If i as developer want to make declarative code with combination of
> `Array#map`, `Array#filter` or `Array#reduce` - i
Those two PRs are about removing implementation-defined behavior from
`typeof`, making it *more* reliable - there is no trend away from using and
relying on `typeof`, full stop.
`Symbol.hasInstance` is a part of why `instanceof` is actually unreliable -
because user code can hook into it. It
Are you perhaps looking for https://github.com/tc39/proposal-set-methods ?
On Tue, Jul 9, 2019 at 1:18 PM Oğuz Kılıç wrote:
> Yes, I already consider it as an enriched version of the current set
> method, I just like calling it superset :)
>
> On Tue, Jul 9, 2019 at 11:05 PM Григорий Карелин
>
As much as I like vim, this seems like more of an argument against using
vim than anything for the language - also it's not "usually" just 1
frontend developer; altho that may be your experience. I often like to say
it's *never* just one - even if it's you, it's also "you in 6 months", and
that
;> No idea how common of a use case this is; I personally ran across it
>>> when reviewing the source code for marked (specifically the [rtrim
>>> method]). That example only does characters, not strings, but it's used in
>>> the wild by a package with ~2m weekly downloads
`trimStart` and `trimEnd` are better-named versions of the very very
long-existing `trimLeft` and `trimRight`, which lack this ability, along
with ES5's `trim`.
It wouldn't make sense for these three to differ.
It certainly seems like a potential language proposal to add a string
argument to all
again, `Object.keys({ y })[0]` will give you the string `y`, and will
survive refactoring tools. you can even do `function nameof(obj) { return
Object.keys(obj)[0]; }` and then `nameof({ y })`.
Obviously it's slightly less ergonomic than `nameof y` would be - but
adding new syntax is very
`nameof whatever` → `Object.keys({ whatever })[0]`, but I'm a bit confused
why it'd be better to type `nameof foo` in code, rather than `'foo'` - if
you change `foo` to `bar`, you have to change both of them anyways.
On Fri, Jun 14, 2019 at 1:31 PM guest271314 wrote:
> Am neither for nor
(that's not react's creator; that's redux's creator, who is now a member of
the react core team)
On Wed, May 15, 2019 at 8:17 PM Isiah Meadows
wrote:
> Fun fact: React elements are plain JS objects that are nearly
> JSON-compatible. The only reason why they aren't is because of the presence
>
It can already be a getter if you like, which would allow a function to
compute the value on demand.
On Sat, May 11, 2019 at 6:55 AM _ zaoqi wrote:
> Allow Error.prototype.message to be a Function
>
> It is useful in this case:
>
> https://github.com/browserify/commonjs-assert/pull/47
>
>
`import * as Self from '.'` should work in every implementation of ESM
that's shipped so far that I'm aware of.
On Wed, Apr 24, 2019 at 8:39 AM Randy Buchholz
wrote:
> Maybe my example was misleading by using an `import`. What I’m talking
> about is inspecting the module from within itself.
Would this not work?
async function test(promise1, promise2, promise3) {
const val1 = await promise1.catch(); // ignore exceptions
const [val2, val3] = [] = await Promise.all([promise2, promise3]).catch();
await Promise.all([promise1, promise2, promise3]); // throw to caller
return val1
`const` means it can't be reassigned, but a non-frozen value can still have
its properties changed or its [[Prototype]] changed (including Promise,
which could have its `.then` method changed), which would change the type.
On Fri, Apr 5, 2019 at 11:36 AM guest271314 wrote:
> Two possible
`const [a, b] = Array.from(anyArraylikeObject);`
On Tue, Mar 19, 2019 at 7:22 PM Frederick Stark wrote:
> This already works with an iterator, because array destructuring uses the
> iterator protocol
>
> const [a, b] = {
> 0: "ayy",
> 1: "bee",
> length: 2,
> *[Symbol.iterator]() {
>
s extension of class fields
> proposal) seems like it has potential to me, so it seems like an excellent
> time for everyone here to tell me why it's awful and stupid.
>
> On Sun, 10 Mar 2019 at 06:59 Jordan Harband wrote:
>
>> The engine only has that knowledge when you
free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
> <#m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband wrote:
>
>> An addi
An additional keyword like this would require a function to have a hidden
reference back to the instance. However, especially for `class` methods,
but also for ES5-style inheritance, or even for `class Foo {}
Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
billion
https://github.com/tc39/ecma262/pull/1174 adds `export * as someName from
'path'`; https://github.com/tc39/proposal-export-default-from is the
proposal that you're looking for.
On Fri, Mar 1, 2019 at 6:48 AM Mike Samuel wrote:
>
>
> On Fri, Mar 1, 2019 at 1:35 AM Cyril Auburtin
> wrote:
>
>>
story of the
> syntax decisions?
>
> --David
>
>
> On Feb 25, 2019, at 12:33 PM, Jordan Harband wrote:
>
> Additionally, https://github.com/tc39/proposal-pattern-matching - switch
> statements are something I hope we'll soon be able to relegate to the
> dustbin of history.
&g
That only allows you to switch on things that have a string representation;
object identity (more complex than the basic form that switch currently
allows) is a particularly common use case that the pattern matching
proposal addresses.
On Sun, Feb 24, 2019 at 2:36 PM kai zhu wrote:
> if it
Additionally, https://github.com/tc39/proposal-pattern-matching - switch
statements are something I hope we'll soon be able to relegate to the
dustbin of history.
On Mon, Feb 25, 2019 at 6:01 AM David Koblas wrote:
> I quite aware that it’s covered in do expressions. Personally I find do
>
`Reflect.ownKeys(x || {}).length === 0`?
On Wed, Feb 13, 2019 at 10:31 PM Isiah Meadows
wrote:
> This would be roughly equivalent to `Object.keys(value).length === 0`,
> but with a few exceptions:
>
> 1. If `value` is either `null` or `undefined`, it gracefully falls
> back to `false` instead
So effectively, you're arguing that stagnant tools should hold back
evolution of the language, even when non-stagnant alternatives exist?
On Tue, Feb 12, 2019 at 3:26 PM kai zhu wrote:
> > Can you expand on what you mean by this, or provide an example of a
> > feature that can't be "easily
If the superclass constructor has a way to run any code after subclass
constructors, then implementation details of the *subclasses* are then
leaked.
On Sat, Feb 9, 2019 at 2:15 AM Isiah Meadows wrote:
> I've also had *several* scenarios where I could've used this
> personally. I feel ES
Given that you can also do `const c = (...args) => proto.call(null,
...args);`, and `Function.isSameTarget(a, c)` would presumably be `false`,
can you elaborate more on the use case for this?
On Mon, Feb 4, 2019 at 9:38 AM Sultan wrote:
> A way to determine if two bound functions reference the
Typically, APIs that are sometimes sync and sometimes async are called
"z̲̗̼͙̥͚͛͑̏a̦̟̳͋̄̅ͬ̌͒͟ļ̟̉͌ͪ͌̃̚g͔͇̯̜ͬ̒́o̢̹ͧͥͪͬ" - unpredictable, hard to
maintain, hard to understand. The general best practice is that a function
should always be async, or always sync, but never the twain shall meet.
Why "remove" and not `.filter`, to produce a new array?
On Sun, Feb 3, 2019 at 9:56 PM #!/JoePea wrote:
> I sometimes find myself doing things like
>
> ```js
> this.children.splice(this.children.indexOf(child), 1)
> ```
>
> but it seems that it will iterate the array twice. Maybe a new method
I suspect that would break a ton of code - ES6 name inference already broke
some of mine, but I was able to work around it by using this kind of
indirection.
On Sun, Feb 3, 2019 at 11:02 AM Sultan wrote:
> Where there any attempts to allow factory functions the ability to assume
> the name of
There's a difference, though, between private field access - an entirely
distinct and new kind of thing - and normal property access, a
well-established and understood thing.
On Mon, Jan 28, 2019 at 11:53 PM Sultan Tarimo wrote:
> This is expected and by design. For example
i think if i can use something unquoted in an object literal, i'd expect to
be able to use it in dot access - ie, `obj.font-size` - and then that
problem arises.
On Mon, Jan 28, 2019 at 3:43 PM Sultan Tarimo wrote:
> The former as the following is equally invalid syntax errors:
>
> const font =
is that a key called "font-size" or the subtraction of `size` from `font`?
On Mon, Jan 28, 2019 at 1:48 PM Sultan wrote:
> Is there any reason that dash-case keys are not supported in the object
> literal syntax.
>
> For example:
>
> const style = {
> font-size: 10
> }
>
> Compared to what
Something that can be invoked has a `[[Call]]` slot, and is `typeof`
"function".
Adding a Symbol that makes something callable would have a number of
effects - it would make `typeof` (one of the most robust operations in the
language) unsafe, because it would have to access the Symbol method,
In `import * as m from myModule`, `m.default` is already the default
export; `Object.keys(m)` is already the list of export names, and
`Object.entries(m).filter(([k, v]) => typeof v === 'function'))` is the
list of functions.
On Fri, Jan 25, 2019 at 5:27 AM Randy Buchholz
wrote:
> Would it be
Rather than investing more in switch statements,
https://github.com/tc39/proposal-pattern-matching may be more compelling :-)
On Sat, Jan 19, 2019 at 11:23 AM Sm In wrote:
> *Before read: I'm not a native. so I may used some unnatural expression,
> or non-sense sentence. I feel so sorry for
orkflow problems
> most of us js-devs were originally hired to solve.
>
> On 18 Jan 2019, at 11:32 PM, Jordan Harband wrote:
>
> This thread would apply equally well to objects (there's no such thing as
> a "json object" - json is a string, and once it's parsed into
=== jsonStringifyCanonical({
> meta: {label: "point #32"},
> data: {z: 3, y: 2, x: 1}
> })
> );
> }());
> ```
>
>
> [1] testing aa “==“ b by comparing their canonical json-representation
> https://github.com/kaizhu25
It's pretty important that the meaning `===` not be able to change.
On Fri, Jan 18, 2019 at 10:33 AM ViliusCreator
wrote:
> What about having Symbol.equals?
>
> For example, for now this is what it does:
>
> ```js
>
> class Position {
> constructor(o) {
> this.x = o.x instanceof
I'm not sure what you mean, that should certainly be possible today. In
node, I get this:
```
function foo ([a, b] = [1, 2]) { return [a, b]; }
foo([2, 3]) // [2, 3]
foo() // [1, 2]
```
On Thu, Jan 17, 2019 at 9:50 AM Sultan wrote:
> Consider the following is not possible today:
>
>
https://github.com/michaelficarra/proposal-first-class-protocols may be
relevant.
On Wed, Jan 16, 2019 at 9:06 AM Augusto Moura
wrote:
> I don't think string namespaced names are the right feature here
>
> Namespaces are intended mainly to avoid conflicts with names when
> sharing a global
https://github.com/michaelficarra/proposal-first-class-protocols may be a
more palatable approach here.
On Wed, Jan 16, 2019 at 9:41 AM ViliusCreator
wrote:
> Also, using `new (Abc(4, 5, 6))(1, 2, 3)` causes error ` Uncaught
> TypeError: Abc(...) is not a constructor`.
>
>
>
>
>
See https://github.com/zkat/proposal-as-patterns
On Wed, Jan 16, 2019 at 12:24 AM Sultan wrote:
> The ability to both name and de-structure an argument.
>
> Relying on the spread operator does not archive the same effect
> considering that the spread operator "by design" has some short-comings
to help me. Since imports use paths, if I move a file refactoring can be
> painful. With an IDE extension, I can trigger an event when I move a file
> to prompt “Update all imports?”. It can parse my project and update all
> imports to point to the right place.
>
>
>
> *From:* es-di
`.constructor` is unreliable, and can be easily forged - of course,
`Symbol.typeof` would create the same unreliability with one of the few
truly reliable operators in the language.
On Tue, Jan 15, 2019 at 12:38 PM J Decker wrote:
>
>
> On Sat, Jan 12, 2019 at 8:19 AM Randy Buchholz
> wrote:
>
```
var foo = function(a) { console.assert(this === obj) };
var obj = { foo() { return foo.apply(this, arguments); } };
```
?
On Sun, Jan 13, 2019 at 10:01 PM Ranando King wrote:
> Bind is just a wrapper function provided by the engine. You can always
> create your own:
>
> ```js
> function
"who calls function B" has, and must have, no bearing on how function B
behaves. Every single call site that passes identical (`Object.is`)
arguments must behave the same. Am I misunderstanding what you mean?
On Sun, Jan 13, 2019 at 9:50 PM Ranando King wrote:
> That's all fine and dandy until
:
>>
>> Exhibit A:
>> var len = 10
>> var arr = Array.create(null, len)
>> for (var i = 0; i < len; i++) arr[i]
>>
>> Exhibit B: (tuple)
>>
>> var arr = Array.create(null, 2)
>> arr[0] = 'a'
>> arr[1] = 'b'
>> return a
>>
Sorry if I was unclear; it's *impossible* to have an array without a
`.length` own property, and there'd be no way to get the length or iterate
over it if you did. I'm also not clear on why you'd want to store named
properties on an array, especially if you can't iterate it because it
doesn't have
econdary consequence allow engines to make stronger assumptions with
> regards to operations on these structs.
>
> On Thu, Jan 10, 2019 at 9:48 AM Jordan Harband wrote:
>
>> An array with no prototype wouldn't have any of the iteration methods on
>> it; a function with no prototype wo
An array with no prototype wouldn't have any of the iteration methods on
it; a function with no prototype wouldn't have .call/.bind/.apply - length
and name are own properties of functions, and length is an own property of
an array, so you'd get those regardless.
(`Array.from({ length: 1000 })`
`console` isn't part of the language; node and browsers have their own
implementations (which is likely covered by an HTML spec), so you'd want to
look into it there.
node's `util.inspect`, for example, provides a `util.inspect.custom` symbol
that's invoked to get a custom string version of the
import path specifiers are another.
On Wed, Jan 9, 2019 at 10:16 AM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Wed, Jan 9, 2019 at 5:36 PM FERREIRA, ERIC B
> wrote:
> > I contend that adding `NoSubstitutionTemplate`s to the definition of
> > `StringLiteral` will bring the
All the iteration methods are a specific case of reduce, in that you can
implement them all with reduce.
On Mon, Jan 7, 2019 at 11:27 AM Ranando King wrote:
> Isn't that just a specific case of Array.prototype.reduce?
>
> ```js
> const evenNumberCount = [1,2,3,4,5].reduce((acc, val) => { !(val
Is there any evidence that existing arrays *prevent* engines from making
optimizations? I believe (and any implementors, please correct me if I'm
wrong) that the most common approach is to guess the likely maximum size
for the array, double it, and then allocate that much memory - and thus all
the
1 - 100 of 439 matches
Mail list logo
