TC39 considers renaming flatten and flatMap to smoosh and smooshMap | Hacker News Reader

TC39 considers renaming flatten and flatMap to smoosh and smooshMap

github.com

32 pointsggregoire20 comments

Mootools already is in conflict with the latest Ecmascript: https://mootools.net/core/docs/1.5.2/Types/Array#Array:Array...

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)

We also dealt with an old MooTools having an incompatible implementation of Function.bind: 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.

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.

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.

I'm curious what examples there are of TC39 saying no. How many proposals have been withdrawn, ever? That's a pretty low bar for review. Looking higher: are there examples where TC39 has agreed that the quality of a submission was high enough, but where it has decided the feature is not a good fit for the language?

I feel like TC39 is letting anyone with an interest in adding to the language do so. It may take a long long time, may require a lot of technical back and forth, but I feel like ultimately, once the proposal can meet the technical demands required, TC39 will approve the new feature.

A lot of really good things have happened. But I also worry that the language is out of control. Features like pipeline operator or the new smart pipeline operator are daunting and scary capabilities that would make JS vastly less approachable. I don't know if TC39 has the means or spirit to be able to say no.

And at some point, I feel like we need to have some cool-off time to experience what is. We've done so much, so fast. A moratorium on reinventing the language, giving everyone some time to get over the culture shock of it all, and time to practice and learn and experience, so we can collectively learn what the real issues are before carrying on the rapid, fast expansion- it seems in order to me that we have a moratorium, a break, at some point.

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.

They’re correct - if you make a library that is popular enough, and it has (and depends on) some absurd addition to a native object it effectively blocks using that name on the object.

It becomes bad when the library checks for an existing implementation of that function, and then assumes compatible semantics

I disagree and actually like it in principle. Languages of any kind change, and this to me feels just like spoken language change.

If enough people establish convention - why break it? A proposal that goes against convention is already under such scrutiny. I don't believe "smoosh" in this case is any better than "flatten" but I agree with the motivation and that's far more important than one function name.

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.

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

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.

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

I don't see how its absurd. The alternative is you break tons of websites - even worse the user isn't likely to know why, seeing as chrome would auto-update and their sites are broken

you're quoting ljharb's hardlining. ljharb is a sociopath. he's playing policeman & bossing people around on some power trip. he thinks he gets to play the savior of the web & plays all high & mighty & snaps at any one who doesn't fall into line.

Relevant: https://news.ycombinator.com/item?id=16551272

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://github.com/tc39/Array.prototype.includes/#why-includ...

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).

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?

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

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.

Reply on news.ycombinator.com