tes in the object initializer. Particularly not with the
well-established convention of using camelCase in that situation when
interoperating with objects that have (or act like they have) dash-named
properties (like the CSSStyleDeclaration object on HTML elements).
-- T.J. Crow
On Sun, Jan 20, 2019 at 11:05 PM Frederick Stark
wrote:
>
> There's also https://prop-tc39.now.sh/...
(Interested, he clicks link.)
> ...which is much more readable.
(Recoiling, he reminds himself that "more readable" is a **deeply**
subjective concept. ;-)
y = ${this.y}, z = ${this.z}`);
}
};
};
const obj = new (Abc(4, 5, 6))(1, 2, 3);
obj.show();
```
https://jsfiddle.net/gh3dv297/
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
js
new Abc`4, 5, 6`(1, 2, 3)
```
(parsing the "arguments" in the template from the strings array passed to
the tag function).
`new (Abc(4, 5, 6))(1, 2, 3)` starts looking pretty good. :-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
for boundThis.
But I'd be interested to know how difficult it is for JavaScript engines to
implement, since Empty is largely a spec-level concept and it's valid (in
strict mode) to use `null` and `undefined` as boundThis...
-- T.J. Crowder
___
es-discuss
luated if the assertion failed, as though you'd written:
```js
if (a !== b) {
throw new AssertionError(`a (${a}) !== b (${b})`);
}
```
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
e containers without their usual
features seems like a bad idea^H^H^H^H^H^H^H^H edge case best handled
by `setPrototypeOf` and `delete`. :-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
se the
array from the first call to call the tag function the second time,
what if the function modified the array? (Presumably if it *is* a
change, that's *why* it was changed... :- ) )
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
`bar`};
```
...but this failing:
```js
const obj = {`I have a space ${x}`: `bar`};
```
...because that's not a NoSubstitutionTemplate and so it needs to be a
computed property name.
Are there other places?
-- T.J. Crowder
___
es-discuss mailing l
e end. It won't come
up in the simple use case of passing along the strings and subs in a tag
function (`subs` will always have one fewer entry than `strings`), but it's
slightly more general-purpose if it tacks them on the end.
`String.interpolate` wo
On Thu, Dec 13, 2018 at 6:37 PM T.J. Crowder
wrote:
>
> But called normally, it's a useful helper, for instance in
> Isiah's `escape`...
Going through the process of the example for my message just now made me
think more about this function. Suppose it:
1. Accepted an array of subs
On Thu, Dec 13, 2018 at 5:56 PM Mark Miller
wrote:
>
> I like String.cooked best. While I agree that method names should
> generally be verbs, I suggest this rule should *not* be used for
> template literal tag names.
Fair enough, but the primary use of this function is *not* using it as a
tag
t some point, or investigations have proved it's not
worth the trouble.)
I'm not bothered either way.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
. There
don't seem to be concerns that it's half-baked.
(I'll stop now.)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
strings already work well enough.
Agreed.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
it would be an
optimization target (being a standard operation).
I find the name `identity` unilluminating, though, partially because it's
not quite the same meaning as the usual "identity" function (`function
identity(x) { return x; }`), though it's close. `assemble
On Tue, Dec 4, 2018 at 7:08 PM T.J. Crowder
wrote:
>
> I believe there already is one:
> https://github.com/tc39/proposal-decorators/issues/69
Apparently there was a poll (**really** wish someone had mentioned it
here, following ALL contributors to proposals on twitter is not
scalabl
t further. But it all starts, to my
mind, with that thorough read, and respect for those who've been in
this trench for some years now. :-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
but it doesn't really buy
you anything.
Be interested to know more about why you want non-function callable objects.
-- T.J. Crowder
[1]: http://jsfiddle.net/8qvpc7Lh/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
you put
`export` in front of it" (in the simple case). Breaking that for decorated
classes seems like a horrible idea.
TC39 is meeting this week. Here's hoping they come to resolution on this
stuff and, as is usually the case, a good one that makes sense.
-- T.J. Crowder
___
r/educators/notes-2018-10-11.md
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Nov 30, 2018 at 5:49 PM T.J. Crowder
wrote:
> which is
>
> ```js
> class Example {
> ...
> }
Apologies, that "which is" at the end of my previous message should have
been:
```js
class Example {
second;
#third;
fifth;
constructor(first,
list I'd design without a really, really good reason, but...
Food for thought.
-- T.J. Crowder
[1]: https://github.com/tc39/proposal-class-fields/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
been true of
all of the suggestsions in this thread).
-- T.J. Crowder
[1]: https://github.com/rtm/js-pick-notation
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
be so
project-specific that it's unlikely to go into the standard library.
I'll step back at this point.
Best,
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Nov 27, 2018 at 5:14 AM Ranando King
wrote:
Do you have any evidence to back up the assertions in the Motivation
section? I haven't seen an issue with people making odd design
decisions "just" to make properties own properties.
-- T.
use a Proxy, or...
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
le.log(e2.x.y); // 0
```
Once decorators are up and running, doing this could be a decorator, though
I submit it's an edge case.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, Nov 22, 2018 at 3:48 AM kai zhu
wrote:
> the spread operator was a mistake.
It's neither an operator nor a mistake.
Again, please stop wasting the list's time with re-litigating decisions
that have been made.
-- T.J. Crowder
___
es-disc
rtant from a performance perspective, I'd
expect it to get aggressively optimized.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
benefit to that syntax, since people use class
fields for that use-case which can make mocking difficult.
But I'm not keen on that syntax with the semantics you're proposing.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
alizer [but *not* when assigned to
a property on an existing object].)
;-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
to numeric literals (e.g., `console.log(12..toString())`).
I can see in your commit on the Babel fork that you have allowed for it,
but for those who don't dig that deep...
If this were in the language, I'd happily use it. I don't really feel the
lack of it, though.
-- T.J. Crowder
Oooh, I see.
Fantastic, thank you Mark and Logan!
-- T.J. Crowder
On Wed, Oct 24, 2018 at 7:03 PM Mark Miller wrote:
> Ah. Crossed in the mail. Yes, Alan raises the same issues regarding the
> TDZ vs non-writable worry.
>
> Thanks for the pointer.
>
> On Wed, Oct 24, 2018
e thing was `writable: true` rather than `writable:
false`.
How'd I do? :-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, Oct 11, 2018 at 10:59 AM Andrea Giammarchi
wrote:
> TBH, for consistency sake with everything else in JS, I'd call
> the method `delete`, since it's the one that returns `true` or
> `false` in pretty much every other case.
E.g., in Maps and Sets (and their weak cousins)
s is by intent so as to allow data to be written and
> read with cheap unsynchronized writes and reads, and then for
> the (comparatively expensive) synchronization to ensure proper
> observability.
Fantastic, that's exactly what I was hoping.
Thank you again!
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Oct 10, 2018 at 7:03 PM Allen Wirfs-Brock
wrote:
> Yes, exactly.
Thanks!
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
s `"0"` for both, for instance; operations involving them largely
don't care about the pseudo-sign of 0). Is that the rationale? Basically,
avoid a footgun while ensuring consistency?
Thanks,
-- T.J. Crowder
[1]: https://tc39.github.io/ecma262/#sec-map.prototype.set
[2]: https://tc39.
he syntaxes to
align, I'm just curious where the syntax is headed.)
-- T.J. Crowder
[1]: https://github.com/tc39/proposal-class-fields
[2]:
https://github.com/tc39/proposal-class-fields/commit/4bfde40926d303694b7acd071c13a610ffa1a272
___
es-discus
y be read directly. That's also a "synchronization
edge"?
Thank you again, I appreciate your taking the time.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
o believe I'm just being dense (in fact, it seems likely), if someone
wants to point out a speciific bit... :-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
a bit surprised
that a list admin hasn't dealt with it yet. It's been allowed to go on for
far too long. As always, constructive input on something being proposed is
great. Constantly banging on that everything since ES5 made life worse is
just noise (and would be even if it were true).
-- T.J
that doesn't happen with JavaScript's memory model?
That seems unlikely to me, I'd want a canonical source on it. But I could
imagine (and this is pure invention) that using an `Atomics` method on a
buffer, in addition to ensuring no reordering etc., also triggers a
cache-flushing event or similar.
-- T.J. C
in advance,
-- T.J. Crowder
[1]:
https://stackoverflow.com/questions/52445807/does-postmessage-or-yielding-to-the-event-loop-or-similar-sync-shared-memory
[2]:
https://hacks.mozilla.org/2016/05/a-taste-of-javascripts-new-parallel-primitives/
___
es-discuss
On Tue, Aug 14, 2018 at 7:42 PM, T.J. Crowder
wrote:
> I must be misreading those or something, but as far as I can
> tell, they both (I think they're basically the same thing)
> just give you a specific generator object, not
> %AsyncIteratorPrototype%: http://jsfiddle.net/urv04L
ically the same thing) just give you a specific
generator object, not %AsyncIteratorPrototype%:
http://jsfiddle.net/urv04Lp7/
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
globally exposed like `Function` is. None of the new subclasses of
Function constructors are exposed; according to [this thread][1], there
weren't enough strong use cases [that thread is for `GeneratorFunction`,
but we can extrapolate].)
-- T.J. Crowder
[1]:
https://esdiscuss.org/topic/why
is unambiguous and offers a path to extendibility, but Date already goes a
different way...)
This parallels Date handling and seems a reasonable stop-gap until the next
thing after JSON.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.or
SON` which validated and parsed the string in that format.
This would put us where Dates are now, but without competing standards for
them (ISO string vs.` /Date(epochval)/`).
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
http
pt's features is nothing new. JSON
doesn't handle Date instances, Maps, Sets, or Symbols as values either
(much less Symbols as keys).
But JSON support for BigInt (or BitInt support JSON, whatever) is
something to pick up in [its thread][1], not here.
-- T.J. Crowder
[1]: https://esdiscuss.org/topic
ful.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
const {first, age} = person;
result = {first, age};
}
```
If/when `do` expressions:
```js
const result = do {
const {first, age} = person;
({first, age});
};
```
None of which is pretty either. :-)
-- T.J. Crowder
___
es-discuss mailing li
On Wed, Jul 25, 2018 at 12:02 PM, Herbert Vojčík
wrote:
> If we get do expressions, we can, afaict, simply do...
Very good point. It's nicely concise, too.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.
ad horse.
I'm not going to keep writing these replies, I'll just refer to this one
from now on.
And again, lurkers, please weigh in.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ding your intent?
-- T.J. Crowder
[1]: https://github.com/tc39/proposal-class-fields
[2]: https://github.com/tc39/proposal-static-class-features/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
(or possibly both entry and exit) or when the
application code asked it to.
I think this thread is getting fairly off-topic for this list, though.
Perhaps do up a full runnable MCVE and post a Stack Overflow question or
similar.
Good luck with it!
--
, is the current parlance?), and if you
want notifications of changes just to those properties, I think
monkeypatching will be your simplest and most successful approach.
If you need to catch additions as well, I don't think there's any solution
other than diffing, which is quit
ut again: I'm sure constructive, research-based input on how to deal
with JSON issues related to (for instance) BigInt would be welcome in
that BigInt thread and, ideally, eventually a proposal. There's no
need for some big conceptual argument over the course of the language
-- that *is* a
anything but sugar.
The accurate statement would be that `class` lets you do things you
couldn't do in ES5. But so does `Reflect.construct`. I believe it was
important to the "no `new`" crowd that a non-`class` mechanism existed for
creating objects using Error and Array as prototype
On Tue, Jul 24, 2018 at 12:28 AM, Steve Fink
wrote:
> Or perhaps `in.own` should be Object.prototype.hasOwnProperty.call(obj,
> prop)?
It should just use the abstract [HasOwnProperty][1] operation directly.
-- T.J. Crowder
[1]: https://tc39.github.io/ecma262/#sec-hasownpr
Either subclassers would have to handle that, which they will forget to do,
or it has to be a bit more complicated than just a simple fallback to `
Promise` (I don't immediately know what that "more complicated" answer
would be.)
-- T.J. Crowder
___
es
On Thu, Jul 19, 2018 at 2:44 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> Is there anyone appropriately-placed who can say "Yeah, if someone spends
> the time to investigate this and put together a really proper proposal,
I'm
> willing to look at that proposa
On Thu, Jul 19, 2018 at 12:32 PM, Andy Earnshaw
wrote:
> Although I support the idea of `!in` (for the same reasons as T.J. Crowder
> mentioned, plus it's useful for duck typing), what some browsers do isn't
a
> great argument as modern browsers follow the spec more closely wit
On Thu, Jul 19, 2018 at 9:49 AM, Isiah Meadows
wrote:
> What about this alternate proposal:
Great minds: https://esdiscuss.org/topic/fwd-feature-proposal#content-5 ;-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
ht
the original array). But it does with `forEach`, `find`, `some`, etc.:
```js
const objects = [
{id: 1, type: 1},
{id: 2, type: 2},
{id: 3, type: 2},
{id: 4, type: 3}
];
console.log(reversedView(objects).find(o => o.type === 2));
```
Finds `{id: 3, type:
nd ES2015):
* Lodash implements both `findLastIndex` and `findLast`).
* Underscore, PrototypeJS, and MooTools don't as far as I can see from the
docs.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
return n * a;
};
return foo(n);
}
```
Again, I really don't like that, but it does defer init.
Given how easy this is with block scope or, as Ben Wiley points out, module
scope, I think there would need to be a stronger use case.
-- T.J. Crowder
_
wrote:
> So I agree this is a Really Bad Idea™, for this above if not the Kotlin
> reference.
I strongly disagree it's a Really Bad Idea™. I think it's a Moderately Good
Idea On The Whole™. And `!in` is fine by me but I'm also happy with `notin`
or whatever.
I just don't expect it to happen.
e
> might not be.
Heh, whereas despite having written that first bullet in the footgun column
somewhat forcefully (looking back), I go the other way. :-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
lity about it.
In the YAGNI and/or footgun column:
* People already get objects and arrays confused enough! At least
right now, if they write `[foo: "bar"]`, they get a syntax error
(though of course `{0: "bar"}` is perfectly valid). Don't hand them
yet another footgun.
* As you sa
(array); // [, , 42];
```
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
js
if (!('x' in obj || 'y' in obj)) {
doit()
}
```
That said, I've wanted !in many a time, in a minor sort of way...
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
every time you need to do a case-insensitive
comparison; instead, I'd drop a utility function in my standard lib
somewhere.
I like that approach to creating that utility function, though. :-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
hotspot for execution, it'll get
aggressively optimized either way. If it isn't, you don't care.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
t just that the strings are equal or not equal, but
how they relate to one another lexicographically. For instance, for sorting:
```js
const array = ["c", "a", "B"];
array.sort((a, b) => a.localeCompare(b, undefined, {sensitivity: "base"}));
console.
larly, this should be
> invalid.
> }
Andrea was using syntax from the [class fields proposal][1], currently at
Stage 3 and fairly commonly used via transpilation (he said "class fields"
later in the post, but didn't emphasize it).
-- T.J. Crowder
[1]: https://git
at's as much detail as I
need to get into.
Thanks again all!
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
but having guaranteed-unique values was still useful, and
found application (amongst other places) in solving the problem of adding a
default iterator to `Array.prototype` without name conflicts with existing
code in the wild?
Thanks,
-- T.J. Crowder
___
On Fri, May 25, 2018 at 1:58 PM, Isiah Meadows <isiahmead...@gmail.com>
wrote:
> I'm aware
> that if you assume it's an array, the length will update itself, but
> it won't on array-likes.
Ah, fair enough, supporting array-likes.
-- T.J. Crowder
___
wanting a version of `push` that returns the array.
`pushAll` looks good to me. (Re the desugared code: You don't need
that `this.length = index` at the end, though. :-) )
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
* Firefox v60: 500k - 510k
* Edge v41: 650k - 660k
* IE11: 250k - 260k
* IE8¹: 5.25M (!) - 5.26M
Using `dest.push(...source)` [instead][2] gave the same numbers as
above on Chrome, Firefox, and Edge.
So two reasons: Returning the array, and not pushing (no pun) the
limit. ~125k entries isn't all th
We have two threads going on this with the same (and differeing)
points being raised in both, let's pick it up in the better-named
["Array.prototype.append?"
thread](https://esdiscuss.org/topic/array-prototype-append).
-- T.J. Crowder
Farsight Software Ltd | 20-22 Wenlock Road, Lon
as are given, as with `push`:
```js
Object.defineProperty(Array.prototype, "append", {
value: function(...items) {
for (let i = 0, len = source.length; i < len; ++i) {
this.push(item[i]);
}
return this;
tions. This version assumes all entries are array-like and should
have their entries added to the array on which it's called. There are a lot
of other designs one could make, though. Just one argument (you can always
chain); a flattening version; etc., etc.
-- T.J. Crowder
___
were to try to expand everything.)
Yeah, this is just a weak area for me. Apologies all. I should have just
kept clicking, but when I got to *BitwiseXORExpression* I figured I *had*
to be off-piste. ;-)
-- T.J. Crowder
___
es-discuss mailing list
es-disc
od reason not to include
*PrimaryExpression* in *AssignmentExpression* directly (ambiguity or some
such).
**Thanks!!**
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
t, and I'm sure it
isn't for a reason.
It's a dead simple thing, clearly (and embarrassingly) there's just some
fundamental point or concept I'm missing.
Thanks in advance,
-- T.J. Crowder
[1]: https://tc39.github.io/ecma262/#sec-assignment-operators
[2]: https://tc39.github.io/ecma262/#prod-A
tc39/proposals). It's going to take accepting that if
*you're* not sure something is useful, if you can't present a compelling
use case that benefits a significant fraction of JavaScript programmers,
then spending your time and ours writing it up and posting it to the list
is actively counte
with
combining marks. If it's a pain point for someone, they can always propose
a locale-specific mapping function standard, perhaps for ECMA-402...
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
n? If so, the footgun available (iterating code
units rather than codepoints), could be an argument in favor...
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
`.map` added, it would presumably visit characters, not
code units, as well; it would be the only reasonable thing to do, both in
light of how strings iterate and just general utility/appropriateness.
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozil
y’d all made a big mistake in coming down from the
trees in the first place. And some said that even the trees had been a bad
move, and that no one should ever have left the oceans.
*(With apologies to Douglas Adams)*
-- T.J. Crowder
___
es-discuss mai
uot;basenet": [ "supernet": gpi = new Network().typeOf({
starTopology:[[0,1,..],[2,3,..],..] }) ] ];
```
...which do the same thing?
Does this call on any prior art?
What problems does it solve?
-- T.J. Crowder
On Tue, May 8, 2018 at 10:53 AM, Abdul Shabazz
<ahshabazz2
s almost always a bad idea.
@somonek, an object with an array of keys is probably your best
solution. Wrap it up in an object with an API that all of the code
updating it can use, so you don't have consistency issues. You could
even give it an iterator. :-)
-- T.J. Crowder
_
.but I don't think that, or `keysIterator`, really helps somonek vs. what
he's doing now (`Object.keys`).
-- T.J. Crowder
[1]: https://tc39.github.io/ecma262/#sec-enumerate-object-properties
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ed outage, but clearly someone's on it
(now).
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
casions, the way I'd use would be `["whateverName",
whateverName]` (granted it's more verbose at the call site). That's
what `Object.entries` and `Map.prototype.entries` do, for instance,
and it's friendly to destructuring:
```js
function example([name, value]) {
console.log(`${name} = ${value}`)
n so I can't check the 2016 or 2017 snapshots [note to
self: keep local copies!]).
Agreed it's not the best way to go about it, though. :-)
-- T.J. Crowder
[1]: https://tc39.github.io/ecma262/#sec-object-type
___
es-discuss mailing list
es-discuss
the first two. Also has the
advantage that you can easily change how many you show before the "See
more."
-- T.J. Crowder
On Tue, Apr 24, 2018 at 3:41 PM, somonek <somo...@gmail.com> wrote:
> The use case is:
> (long story short)
>
> I have an array of items coming fr
1 - 100 of 398 matches
Mail list logo
