prevent-smoosh VS proposal-flatMap

Yes. Some folks who variously:

a) didn't know how to recognize a cheeky straw man proposal

b) didn't know how to take a joke

c) didn't agree with (or understand the importance of) the never-break-the-web imperative that TC39 operates under (turns out this is a lot of people)

tried to do exactly this to "prevent smoosh":

- https://github.com/staltz/prevent-smoosh

- https://twitter.com/andrestaltz/status/971500672620351494

Mostly, though, they just taught TC39 to have less fun and to ignore the "just break the web it's okay!" crowd.

Why TC39 operates under this never-break-the-web imperative: because if they didn't, every proposal they consider might devolve into an unresolvable discussion of "well is THIS thing important enough to break the web over? how much usage would this change break? how valuable do we think this is?". The easiest, and only, way to resolve all possible such discussions is to just not have them.

If you're doing a series of mutations specific to a custom type in that fashion, then there isn't much benefit. But imagine you want to chain operations on an existing type, whether it's a built-in like String, or a type introduced by a different package like sqlite.Database. To use method chaining you'd have to monkey-patch them, which can lead to all sorts of problems: colliding with other packages that want to monkey-patch the same types, confusing the reader when unfamiliar and seemingly undocumented methods appear (why does the SQLite documentation not mention this sqlite.Database#drop method? Which of my installed packages added that? ), your package breaking when the thing you're monkey-patching changes its API, altering object iterations, etc. The troubles with Prototype.js and MooTools in the '00s showed some of the headaches monkey-patching can lead to when it comes to JS especially, where users expect ever-changing browsers to work with 25-year-old code. (I still support changing flatten to smoosh, though.) You might subclass the existing type or encapsulate it in a new type, but then you're potentially breaking the user's typechecking, preventing the use of any other packages that want to do the same thing, escaping tree shaking, and becoming incompatible with unexpected types (what if the user already subclassed sqlite.Database themselves, and want to apply your transformation to that?).