rename flatten to smoosh

[michaelficarra]

As reported in Bugzilla bug 1443630, 8+year old versions of MooTools conditionally define an incompatible version of Array.prototype.flatten. See mootools/mootools-core/Source/Core/Core.js for the responsible code. In an attempt to turn a negative situation into a positive one, I am taking this opportunity to rename flatten to smoosh.

[jdalton]

What percentage of sites does this affect?

[TrySound]

What is this word?

[jdalton]

[TrySound]

How about squash?

[js-choi]

See also IRC #tc39 from today.

[domenic]

I think we should rename flatMap to smooshMap in this case. (Not kidding.)

[jdalton]

[mrm8488]

We should rename object to dictionary too...

[sindresorhus]

Swift recently renamed flatMap to compactMap, for clarity. How about Array#compact and Array#compactMap?

[jdalton]

I know compact as array.filter(Boolean)

[zloirock]

In this case, compact already taken: https://sugarjs.com/docs/#/Array/compact and http://api.prototypejs.org/language/Array/prototype/compact/

[zloirock]

Array#flatten already added to core-js -> babel-polyfill, I hadn't any issues about it, so that means at least that it does not break any sites where they used together with MooTools.

[zloirock]

(Sure, MooTools used mainly in ancient sites, but I had many issues about compatibility with also ancient PrototypeJS.)

[brunolemos]

Please let's not add ~lame~ non-optimal method names to a language specification (which is basically permanent) to avoid some libs and old websites from having to upgrade themselves.

We can use a gitbub bot to search and create an issue on all affected repositories, for example.

Flatten is the intuitive name for the feature? So that's what should be used.

[realityking]

What’s the incompatibility between the two implementations? Is it just the default value for the depth parameter? If so, how about aligning with Mootools?

[callmevlad]

I've opened up an issue with Mootools: https://github.com/mootools/mootools-core/issues/2797 - however, they have not had a release in more than 2 years (which should hint at it's usage/adoption level), so I'm not too optimistic that they might change their implementation.

[Haroenv]

What about importing native prototypes? As in import Array.prototype.flatten from “web”

[nilssolanki]

I'm also in favor of squash, as smoosh isn't intuitive for many non-native English speakers.

[ljharb]

@callmevlad unless you could get all sites using older mootools to upgrade, it wouldn't make a difference.

@Haroenv that would conflict with https://npmjs.com/web

[Haroenv]

@ljharb, I meant the idea, syntax could be different to avoid conflict. For example add prototype { flatten } to Array, which can only be the native one

[nafg]

Other name for flatMap are chain, join, bind

[zloirock]

@Haroenv for this case, we already have bind syntax:

import flatten from 'Array';

array::flatten();

but it's not very convenient. Real prototype method without any imports / extensions much better.

[Haroenv]

I get your point, but it would avoid the conflict. I would assume that build tooling can be set up to add the binding of prototypes by default to the native ones, which would avoid the hassle.

Seeing as how many times we see conflicts, having a way to definitely avoid them, rather than trying to find the least breaking name would be interesting IMO

[gkatsanos]

// edited from author. core of message : Mootools should not influence the new spec https://libscore.com/#MooTools

[ljharb]

@gkatsanos this is the second comment you've made on this thread that's inappropriate. I'll point you to our code of conduct - if you continue to be hostile, further moderation steps will be taken.

To answer your question, browsers care about Mootools (and users of sites that use Mootools), and thus so too must everyone.

[jsg2021]

Seriously? prototype polution has been frowned on for years with warnings that if you do, your site may break... Are we really backing down from that warning and letting these old sites dictate our future?

What’s the point of warning and cautioning developers if don’t honor our warnings?

[gkatsanos]

@ljharb My wording was inappropriate but judging from other comments, and on twitter, the core of my message is the popular opinion.

I urge anyone who is against not using "flatten" in the official spec in order to accomodate an anti-pattern of "Mootools" to upvote this comment.

Was this thread opened in order to see what the popular opinion is? In that case the native JavaScript language should not change it's upcoming new specs in order to accomodate obsolete libraries. I don't even understand why we're discussing it.

Aren't there IE6,7,8,9 quirks that the new JS spec doesn't support and the opposite? Definitely so. So why all this talk about a library not in use since years? Is there interest because one of its' creators is involved in TC39 or something?

[ljharb]

@gkatsanos No proposal will be added to the language that breaks websites; the entire process is built around that axiom.

If that happened, then browsers would refuse to ship it, and then nobody would be implementing the spec - the spec only matters in the context of implementations - and implementations won't break their users. Note that it's the USERS of the website - not the people who made Mootools, or chose to use it - that would suffer if those websites are broken. Quite simply, it's user-hostile and shows a lack of empathy to even consider breaking those users for the "crimes" that developers perhaps committed.

[gkatsanos]

@ljharb I understand your point of view, and I disagree with it. You cannot have progress if you have to satisfy each and every JS library created from the inception of JS libraries.

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?

[jacobp100]

Something like innerConcat or concatContents?

[arpowers]

Rule 1: don't get cute. Rule 2. There are no other rules.

[ljharb]

@gkatsanos it's the entire committee's point of view. 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.

[egeriis]

Just curious, bit what’s the threshold for a library to be taken into account when speccing future JS?

My point is, if someone made a framework with an incompatible Array.prototype.squash, how many websites should use this in order for it to have an impact on future JS specs?

[zloirock]

@ljharb breaking some minor sites (which can be fixed) vs confusing thousands of developers - what's your choice? We should explore how many sites it can break. As an option - we can make it compatible with MooTools without changing the name - Infinity deep by default. The same deep used in SugarJS. Interesting, why no one explored compatibility this proposal with popular libraries before.

[ljharb]

@zloirock the committee's choice has been and will continue to be, not breaking any sites if it can be avoided.

The option of making the depth Infinity by default is something I'd like to see, rather than renaming - but that's a separate question. In a state where it breaks sites, the proposal simply will never progress, full stop.

[gkatsanos]

@ljharb how many websites? What is the threshold? https://libscore.com/#MooTools : it's realistic to say the number is so low that directly contacting the webmasters of these websites is feasible.

[ljharb]

@gkatsanos if you wanted to do all JS developers a solid, you are more than welcome to try to contact every website that this proposal breaks, and get them to update.

[arpowers]

I agree with not breaking sites, regressions like that are a huge pain. And thats the best rule to follow for a standard.

IMO if there is a conflict, Array.prototype.flat seems to work fine.

[brunolemos]

Here's another point to consider: Not all old-websites-using-mootools are using the flatten method. In fact, probably a very small proportion of it. So the majority of them may not even break.

EDIT: This hypothesis would need to be tested as it seems mootools itself use flatten in a couple files.

[gkatsanos]

@gkatsanos if you wanted to do all JS developers a solid, you are more than welcome to try to contact every website that this proposal breaks, and get them to update.

@ljharb I'll take 3000 if you take the other 3000. (I am serious)

[jdalton]

FWIW browsers make informed decisions to break sites all the time. I think data is a good thing to collect to help make those kinds of calls. I'd also dig creating a solution to global builtin prototype pollution all-up. Whether that's module safe builtins, new builtin modules for method additions, fancy realm APIs, etc.

[zloirock]

https://github.com/tc39/proposal-string-replace-all/issues/5

[zloirock]

https://github.com/mathiasbynens/String.prototype.at/issues/6

[depoulo]

I'm definitely no expert but what if in browsers, new prototype methods were only available in es module context, (or in 'use strict' context)?

[timwienk]

@brunolemos commented:

Please let's not add lame non-optimal method names to a language specification (which is basically permanent) to avoid some libs and old websites from having to upgrade themselves.

We can use a gitbub bot to search and create an issue on all affected repositories, for example.

Flatten is the intuitive name for the feature? So that's what should be used.

Can we listen to this? :-)

Cross-posting part of my own comment at mootools/mootools-core#2797, assuming most people don't look there:

MooTools' aim has always been to help improve the JavaScript landscape, and I'd like to think we really did help do that.

In my opinion, the worst thing to do is to settle for a bad name for a JavaScript API, because a JavaScript library decided to use it first.

API should be decided on because of how intuitive it is, which means it should at least be logical, easy to understand and if possible in line with established names in other languages.

Anyway -

I'm sure we can look into updating this API on the MooTools end, but it won't really change what happens to old projects.

It should work in such a way - but I'll have to double check if that goes for all versions - that old versions of MooTools Core just overwrite a native method if it exists. For a new version, it should then only place the method (with new API) if it doesn't exist.

This way old projects continue to work fine (since their code will expect MooTools Core's flatten and will get it), new projects (with an updated MooTools Core) will have the new method.

I believe the only difference with MooTools Core's flatten is the depth argument. MooTools Core flattens recursively, while the TC39 proposal only goes up to depth, which defaults to 1. Is this API final?

[Andarist]

Just like @jdalton & @zloirock - it should be backed by data, the whole premise of not breaking the web is as said broken (😉), maybe not by ecma committee but by browser vendors and users (not developers) get affected by this and somehow we do not hear about many cases of angried users because of that.

[heejongahn]

I respect the committee's decision to avoid breaking existing web whenever possible. Yet it won't really make sense to use sub-optimal naming for the spec because of single personal website right? I think establishing (or at least trying to establish) some sort of threshold(percentage/# of sites/etc) can be beneficial to both end users and devs. Easier said than done, but still...

[zloirock]

In PrototypeJS Array#flatten also has Infinity deep.

[zloirock]

So, actual proposal is incompatible with all popular libraries which extends built-in prototypes:

• MooTools
• PrototypeJS
• SugarJS

I don't think that it's possible to break usage flatten for them all.

I see only 2 ways:

• Use Infinity depth. But it will cause some problems in flatMap which haven't depth argument and now is shallow by default. And this does not guarantee the absence of other problems - MooTools version flattens not just arrays.
• Rename. smoosh looks too ugly, maybe just flat?

[Andarist]

I don't think that it's possible to break usage flatten for them all.

The fact that they monkey-patch prototypes doesn't immediately mean that all consuming websites are relaying on flatten/flatMap & and even if they rely on it percentage should go even lower for people who rely on them working with Infinity depth.

It's all just theoretical though, vendors should collect data about this that could provide a clear direction for this proposal.

IMHO using static instead of prototype methods would fix this "problem" in a clean way either way.