Reshaping the Extensions proposal

[nesk]

Pretty much like @hax did before in tc39/proposal-bind-operator#56, I'd like to suggest reshaping the Extensions proposal.

There's been no updates to the proposal for more than two years, despite the fact that it could help a lot of developers with real-world use cases.

I'd like to suggest an alternative to what's been worked on. Essentially, it consists to reduce the scope furthermore and make all functions usable as extension functions without any new syntax or operator, something like that:

function countWords() {
  return this.split(/\s/).length;
}

// Any function within the current scope can be called with a receiver:

"Hello, World!".countWords();
// Returns: 2

I already have a lot of things in mind to provide a specification of this reshape, what should I do to make this happen?

I see in tc39/proposal-bind-operator#56 that @hax had to create a new proposal. Should I do the same? Or can we work together to reshape the current proposal? (if you agree @hax)

[ewinslow]

make all functions usable as extension functions without any new syntax or operator

FWIW, I suspect new behavior without new syntax will just be a complete non-starter as it will break code in the wild.

Are you already aware of the proposal over at https://github.com/tc39/proposal-call-this? I think it is quite decent and gets 99% of the way to what you're talking about here, with mainly some syntax bikeshedding to do :).

[nesk]

As you might have seen in the proposal topic and the linked proposal document, the runtime would not change unless the code is already broken.

Imagine we have the following code in production:

function includes() {
  return true;
}

[1,2,3].includes("hello"); // Returns false

Once extension functions are available, the code still runs the same way because prototype functions always take over extension ones.

However, an already broken code could change its behavior, take the following code:

function hello() {}

[1,2,3].hello(); // Uncaught TypeError: [1, 2, 3].hello is not a function 

Once extension functions are available, this code will no longer throw an error. This could be an issue.

I'm aware of the call this proposal and its really neat, I just wanted to provide an alternative I find easier to read. Utimately, I want developers to be able to easily chain methods, no matter the proposal, the call this one is fine too :)

[ewinslow]

Fair point. Unfortunately I fear that strategy comes with some issues of its own:

1. Any class on which you call such a function cannot later add a method with that same name, lest they break you. This could really limit the Web's ability to evolve its APIs since it's even easier to use than Array.prototype.foobar = foobar but has similar impact. Unfortunately, Dart, Kotlin, Swift, C#, and perhaps others made this exact mistake with their extension methods design, and IMHO are the worse for it. My company's style guide says "don't extend types you don't own" which seriously damages the value of extension methods in my mind.

2. Any symbol foo in scope that might be used to resolve a method called by the same name cannot be readily tree-shaken, since you cannot tell whether it will be invoked or not just by looking at the source code. We should want any developments here to result in more tree-shaking, not less.

[hax]

As I understand, it's very unlikely that the engines would agree to change the current semantic of obj.countWords(), whether first lookup function countWords in current scope or only fallback to function countWords if fail to find it in prototype chain. The main point is engines has too many and complex optimization on dot operation which is the very core semantic of JS, it's very risky to change that.

But I have the plan to reshape the proposal, change the syntax to close to normal method, such as obj.ext%%method and obj.%%method, and represent the updates in future tc39 meetings. (Note %% is just a placeholder of syntax TBD)

@ewinslow I also think your idea of tree-shakeable methods is very important, maybe you could cochampion this proposal :)

[hax]

Some words about call-this proposal, it could be seen as a simplified version of extension proposal. The main differences except syntax are:

• The call-this proposal does not include accessors. I certainly agree that in the entire ecosystem, the use cases for methods far outnumber those for accessors. However, considering that accessors are merely a special form of methods, the lack of support for accessors is regrettable in terms of language completeness and consistency. For example, consider the issue of tree-shaking. Obviously, we hope that the difference between the tree-shakable version and the original code is as small as possible. Making accessors unable to be tree-shakable or forcing them to be transformed into methods introduces additional burdens.
• Another issue is that the call-this proposal requires so-called bare functions (functions require this argument), which has faced considerable pushback in the committee. This is understandable, and it is precisely why the extension proposal avoids exposing or requiring bare functions from the very beginning. (Of course, the committee might change its mind.)

[ljharb]

I remain unconvinced that accessors need any affordance; if you need it, you can extract a getter and use it like any other function.

I don't recall any pushback centered on receiver-sensitive functions - only about the syntax being "worth it". Can you link me to a section in the notes?

[ewinslow]

A snippet of the feedback during my talk last week:

I'm going to go out on a limb and say probably 90% of working JavaScript developers don't understand how this works in method calls at all. And don't care. Don't have to care. Teaching somebody, "well, in this piece of code you have to use double colon and in this piece of code you have to use a period"? Not going to happen. I think that's a social problem and seems to me the technical problem of building a smarter bundler no, matter how hard that is, it's still easier than solving a giant social problem that affects the whole industry.

[ljharb]

I'd slightly disagree with that claim from your talk - certainly I'd think 99% of JS devs don't know all 7 meanings of this, but one thing they definitely all understand pretty quickly is that in a.b(), a is the receiver (the this) inside the a.b function.