Skip to content
This repository has been archived by the owner on Nov 27, 2023. It is now read-only.

Static method naming #57

Closed
Tracked by #54
acutmore opened this issue May 22, 2023 · 11 comments
Closed
Tracked by #54

Static method naming #57

acutmore opened this issue May 22, 2023 · 11 comments

Comments

@acutmore
Copy link

With the new static based functions. I was wondering if there were alternatives to the groupBy name. Object.groupBy and Map.groupBy sounds a little like it operates on Object or Map as opposed to building them.

Background

The majority of static Object methods operate on an object argument:

  • getOwnPropertyDescriptor
  • getOwnPropertyDescriptors
  • getOwnPropertyNames
  • getOwnPropertySymbols
  • hasOwn
  • preventExtensions
  • seal
  • assign
  • defineProperties
  • defineProperty
  • freeze
  • getPrototypeOf
  • setPrototypeOf
  • isExtensible
  • isFrozen
  • isSealed
  • keys
  • entries
  • values

The static Object methods that create an object, Object.create and Object.fromEntries, are in the minority but use words that strongly convey that a new value is being created.

Suggestions

Some alternatives we came up with at Bloomberg:

  • Object.byGrouping
  • Object.fromGrouping
  • Object.groupFrom

Thoughts?

@ljharb
Copy link
Member

ljharb commented May 22, 2023

There’s no clear precedent for this - Promise.all and friends produce a Promise, Object.fromEntries and Object.create produce an Object, Array.from produces an Array.

However, Object.keys/values/entries/getOwnPropertyDesceiptor etc operate on an Object.

@jridgewell
Copy link
Member

I think having the name groupBy is important for recognizability (our own ecosystem precedent and from other languages). I don't think there's a clear pattern for naming factory methods.

@acutmore
Copy link
Author

The recognisability of the name does sound very valuable. So like {_,Lodash,Ramda}.groupBy, in this situation the namespace should be seen as a general collection of utilities. And having Array.groupBy doesn't scale as nicely to having various different collection types.

@nickmccurdy
Copy link

nickmccurdy commented Jun 17, 2023

How about fromGroups? It aligns with existing static methods like Array.fromAsync.

@bakkot
Copy link
Contributor

bakkot commented Jun 17, 2023

@nickmccurdy This method is the opposite of that - your data is not grouped yet, and you want it to be.

@nickmccurdy
Copy link

I was thinking of it more from the mathematical perspective, where the callback is a functor mapping an ungrouped collection to a grouped collection. Though if the result is too arbitrary, maybe fromGrouping would be more clear.

@ljharb
Copy link
Member

ljharb commented Jun 17, 2023

“fromX” means it’s an X already, and as you said, it’s ungrouped.

@Zachiah
Copy link

Zachiah commented Jul 10, 2023

@nickmccurdy correct me if I'm wrong, but @ljharb I think what @nickmccurdy is suggesting is that groups is referring to the function that converts from "ungrouped" to "grouped". An expansion of the name could be: getGroupsFromGroups and when you consider the "more clear" version he provided: fromGrouping, this makes even more sense: getGroupsFromGrouping.

@ljharb
Copy link
Member

ljharb commented Jul 10, 2023

Functions are verbs, so that function could be a "grouper" but wouldn't be "groups", a noun - and fromGrouper sounds like it's a fish :-)

@nickmccurdy
Copy link

I try to avoid putting get in function names as it's usually already obvious. Maybe just groups or grouped could work? Though I'm not sure if they'd have naming collisions.

@ljharb
Copy link
Member

ljharb commented Jul 11, 2023

TC39 reaffirmed consensus today on the existing groupBy name.

@ljharb ljharb closed this as not planned Won't fix, can't repro, duplicate, stale Jul 11, 2023
@ljharb ljharb mentioned this issue Jul 11, 2023
12 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants