Romulo Cintra: Can you help with lights?

It's tooooooo early.

4am in NYC. I just woke up

i went to sleep at 8:30

i don't want to be dedicated i want to be asleep

this was a non-rhetorical question re: hosting, btw (am I just forgetful/unobservant?)

someone want to PR the glossary with that? seems useful

What is it that the static methods is consistent with? Object groupBy?

did i miss the bit where we had bathroom explainations? cc ryzokuken

"Entries" are an array representation of an object. groupBy is an operation on an array.

I like the suggestion for Object.groupBy and Map.groupBy, where you select the return type with the constructor.

"Entries" are an array representation of an object. groupBy is an operation on an array.

I'm not entirely against it, but I'd again rather see something like a formal collector API that those statics could be built off of.

Of a map (and by implication objects-as-dictionaries, which are map-alike)

I like the suggestion for Object.groupBy and Map.groupBy, where you select the return type with the constructor.

Of a map (and by implication objects-as-dictionaries, which are map-alike)

My understanding is this proposal only adds a static to Array right? Is there an addition to Object and Map also and i missed that?

Given users are used to finding helpers like reduce on the array prototype, I don't think it will be obvious to look for these on Object and Map

fromGrouped? like fromEntries? I don't have a better name either

if we're ok with groupingBy it can probably still be on Array.prototype

groupingBy and groupToObject is probably safe... but is this really better than it being a static if we are looking for really weird anmes?

One concern with static is chaining too. Without pipeline you lose the ability to easily chain at the end of array operations.

Object.toCategories?

x.filter().groupBy() is a pretty common thing to want

As I mentioned earlier, I wonder if a comprehensive check for a more general-purpose Array.prototype.collect method would make sense, plus a formalized Collector API.

groop

but you would have an object after groupBy

Using groupBy will be good for discovery.

In what sense? Searching docs?

I am not necessarily opposed to such a thing, but I have a hard time imagining it being as convenient as groupBy. .collect(Collectors.groupBy) is much worse than groupedBy.

Googling “mdn groupBy” on a lark and finding useful results.

the OG ecma is carton manufacturers

well, .collect(Map,groupingBy, fn), really

Googling “mdn groupBy” on a lark and finding useful results.

Carton: the language formerly known as variously ECMAScript and JavaScript.

well, .collect(Map,groupingBy, fn), really

Carton: the language formerly known as variously ECMAScript and JavaScript.

I'm just kinda exhausted with seeing naming conflicts with the ecosystem.

We could seriously consider something like F#'s computation expressions (something jschoi was looking into) to create query DSLs:

// computation expression example using decorators and do-expression syntax:
const array = ...;
const result = @query do {
  for x in array
  groupBy x.name into y
  select y
};

if any of us had large twitter followings we could poll the community on Object.groupBy vs [].groupedBy

I'm less convinced of the efficacy of twitter polls given the mass exodus of many in the tech community off of that platform and onto platforms like Mastodon.

JS does not have room for that

I'm less convinced of the efficacy of twitter polls given the mass exodus of many in the tech community off of that platform and onto platforms like Mastodon.

We need scoped prototype methods

We need scoped prototype methods

if we could get decent sample size in the first place, anyway

Else it's just a pipe.

Jake was talking about this too, but how would it work?

That is the way

I am trying a new language model for the bot, and it's definitely better, but it's slow enough that it gets behind sometimes, and that tradeoff isn't worth it :(

I guess I'll talk about that more when we discuss reflection at this meeting

Anthony Bullard: are you joining the call?

Bradford Smith: Re your iterable suggestion for groupBy, I think we could actually do that. Iterator needs special contiguous-run behavior, but that could be special to Iterator.groupBy (pending the Iterator helpers proposal)

Robert Pamely: Its mine.

[1, 2, 1, 1] in by default groups to a single { 1 => [1, 1, 1], 2 => [2] }, but in infinite iterables it's not possible to collect all values into a key. So instead, you return an iterable [ [1, [1, 1]], [2, [2]], [1, [1]] ] grouping contiguous runs of the same key

[1, 2, 1, 1] in by default groups to a single { 1 => [1, 1, 1], 2 => [2] }, but in infinite iterables it's not possible to collect all values into a key. So instead, you return an iterable [ [1, [1]], [2, [2]], [1, [1, 1]] ] grouping contiguous runs of the same key

grouping only contiguous runs seems like a different operation though, needing a different name to indicate the difference in behavior.

I agree. It feels more like batching the same values or something.

jasew: nicolo-ribaudo https://github.com/bakkot/transcribe-to-gdocs/blob/master/replacements.js

grouping only contiguous runs seems like a different operation though, needing a different name to indicate the difference in behavior.

is the "narrow yes" non-normative notes?

like, I don't think that would pass the TG1 review

Yeah, I'd lean towards something like a .getCalendarField("era"), etc. instead, so that the shape remains stable.

stable, but not very ergonomics 😅

interesting, is era ever placed anywhere other than the end of the date?

True, but it also avoids needing to add more properties in the future that are potentially unused based on the locale/calendar in use.

hm, perhaps I misunderstood something thing. Richard Gibson could you clarify?

rkirsling: can you post your experience here on https://github.com/tc39/proposal-intl-eradisplay/issues?

lack of fast paths for ISO8601 calendar has been a huge pain point as a Temporal implementer so I'm excited to see this progress

rkirsling: Your feedback about the japanese calendar behavior would be best in its own issue; thanks!

but we could maybe just... do something else for proposals that we know will frustrate if we wait till well into stage 3 to do that, and for which we're all already convinced should happen?

in general i'm not really sure. there's very few proposals where this is ever a problem in practice - temporal is a bit of an anomaly