document what qualifies a parameter as too heavy?

[bmeck]

We have various parties that disagree on weight / ergonomics of using an object for a parameter vs 2 function parameters:

CC: @waldemarhorwat , @codehag , @ljharb , @jorendorff , @erights

It would be good to get some matrix of design directions we can take without mandating a specific design. We have various things mentioned.

• Ability to learn the method signature
  • Claim of using an object being distinct from language design precedent in 262
  • Claim of using an object allowing more readability
• Ability to use the method in multiple source text locations
  • Claim of ability to elide unused workflow (insert or update)
  • Claim of ability to use a single parameter / variable to share the handler
  • Claim of ability to use object to store relevant data across usages
• Ability to have minimal overhead in using the method
  • Claim of object allocation in parameter position
  • Claim of ability to re-use handler to avoid allocations

It would be good to clear up each of these claims and prioritize them.

[stiff]

I'm for 2 parameters here. Second function can be defaulted to identity allowing to map.emplace(key, Ramda.always(42)) for just inserts. To reuse arguments you always can do it like

insertupdate = [Ramda.always(42), Ramda.add(42)];
map.emplace(key, ...insertupdate);

Of course not as eloquent as emplace(key, { insert() { return ... }, update() { return } }) but also way more compact and with less curly brackets.

[papb]

@stiff What if you only want an update action?

[stiff]

Good point, with { update: () => ... } it's much simpler. Still possible with something like map.emplace(key, null, x => x + 1)

[dminor]

The new design is focusing on just the insert use case, so this discussion is no longer relevant.