
TC39 considers renaming flatten and flatMap to smoosh and smooshMap - ggregoire
https://github.com/tc39/proposal-flatMap/pull/56
======
marcusarmstrong
Mootools already is in conflict with the latest Ecmascript:
[https://mootools.net/core/docs/1.5.2/Types/Array#Array:Array...](https://mootools.net/core/docs/1.5.2/Types/Array#Array:Array-
from)

No reason to start changing the spec for it now.

(And I say that as somebody that works at a company with what is likely one of
the largest existing Mootools-based javascript codebases around)

~~~
rektide
We also dealt with an old MooTools having an incompatible implementation of
Function.bind: [https://github.com/mootools/mootools-
core/issues/2473](https://github.com/mootools/mootools-core/issues/2473)

Old MooTools is a huge problem child, and did a really bad job being forwards-
compatible with their monkeypatching. They took the half measure of only
monkeypatching things when there was no implementation.

MooTools eventually got it, and changed their monkeypatching behavior to be
more aggressive, such that problem like what we have now wouldn't be a
problem. And they kicked out a minor revision to the older libraries, to use
this more aggressive monkeypatching behavior (at least for bind. dunno about
others?).

Agreed fully: there is no reason to change the js spec for now. MooTools made
forward-compatibility incredibly difficult for themselves, 8 years ago, but
they spent a bunch of effort trying to un-dig themselves out of the hole
since. It's unfortunate, but monkeypatching core JS in this manner was really
un-advisable and irresponsible.

------
v413
Some TC39 members proposed this. It is in no way even discussed or decided by
the TC39 committee yet. The fancy naming is proposed by some as a solution to
prevent name collisions with the flatMap and flatten array methods used by an
old version of the Mootools library. I.e. do not break the web.

~~~
bterlson
Yes, this is by no means normative! Nothing will happen without a long
discussion and consensus among dozens of people. TC39 has a meeting later this
month where I imagine this will discussed in more detail.

Also, assuming we can't use flatten, I am sure we will land on a reasonable
name that is not smoosh.

------
stevemk14ebr
This seems...absurd, from the conversation linked:

Question: "Does this mean that today I can create a new (non existing in the
native spec) method, add it in the native object, using it in a certain
percentage of websites and force TC39 to change it's future implementation
thus essentially hijacking the language evolution process?"

Response: "What that means is that yes, you can create a new nonexistent
method, use it in a certain percentage of websites, and actively destroy any
proposal trying to add that method name. I hope you don't do that, because
that would be pretty sociopathic, but that's absolutely how the process works,
and will continue to work for the foreseeable future.

We've made tons of progress with this constraint, and we'll continue to make
progress with it."

That does not seem like a sensible constraint for language design. Just say
the method name is reserved for goodness sake, you are the ONLY people who get
to exercise that power.

~~~
eridius
Except they don't have this power at all.

If they try and declare a language addition that breaks a non-trivial number
of websites, browsers will _refuse to implement it_. Anything this committee
specs out only matters if it's actually implemented. Browsers care very
strongly about not breaking websites, so the language committee must as well.

~~~
resonantjacket5
lol there's only like 7000 websites that use it. Should we go release 8000
websites with smooshMap and stop them from using it?

~~~
eridius
This very question was already addressed multiple times on the comment thread,
and the answer is yes, that would stop them from using it, and it would also
be a real dick move.

~~~
resonantjacket5
They've already overriden mootools in the past for breaking changes such as
Event, bind, etc. I don't see why they can't do it again

------
gcommer
For context, choosing names for new javascript features always takes this web-
compatibility into consideration. Most famously in the naming of
String/Array.prototype.includes, which was originally going to be .contains
before it was realized that that broke MooTools.

See:

end of [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/String/includes)

[https://github.com/tc39/Array.prototype.includes/#why-
includ...](https://github.com/tc39/Array.prototype.includes/#why-includes-
instead-of-has)

------
scottlamb
Other languages declare some language version to apply to a given source file,
like C++'s --std=c++17 or Rust's (planned) epochs. A word being reserved in a
new standard/epoch/whatever doesn't break existing code using an older one.

Why doesn't Javascript start doing something similar? One mechanism for it
could be a magic comment at the top of the file (sort of like DOCTYPE or
#!/usr/bin/env python3).

~~~
LukeShu
Indeed, in the past there was

    
    
        "use strict";
    

to enable language improvements in ES5. This type of string-command is a no-op
command if the implementation doesn't recognize the string as special; you put
the string-command in there to opt-in to any breaking changes, and then
feature-detect to see if things are there in case you're running on an older
implementation without those changes.

User hrajchert suggested putting this change behind `"use es2019";`. However,
in this case that would be tricky, as the change isn't in language semantics,
but in the standard library's Array type. If there are multiple scripts on a
page that interact, some of which "use es2019" and some of which don't, how do
you handle an array being passed between them?

------
olliej
This isn’t the first time JS libraries get in the way of improving JS.

Do you know why the arguments object doesn’t even get to have the array
prototype?

A bunch of js libraries - I can’t remember which anymore - detected arguments
vs array by looking for .shift and .map or similar on an object and change
there behavior accordingly - net result: a large number of major sites stopped
working.

Similar for nodelist IIRC

------
tejasmanohar
This made me crack up. I'm not a fan of this mindset in general, but prefixing
`flatten` with an underscore (`_flatten`) would be better than `smoosh` IMO.

