proposal-call-this Collaborate with extension proposal

Congratulations on stage 1! 🎉

First of all, I'm strongly supportive of the bind operator things, it is a very good supplementary to the language. Both this proposal and extension proposal has a very similar motivation and similar design, similar semantics on the :: operator. @hax mentioned that the parallel namespace is not an essential part of the extension proposal and can be removed under the temperature of the committee. And the significant difference between the two proposals is the semantics of binding accessors. I'm wondering if it is better for two proposals to collaborate and find a consensus?

Oct 27 '21 12:10 legendecas

@legendecas: Thanks for raising this! @hax (the champion of Extensions) and I have indeed been discussing privately, since August, about ways to reconcile our two proposals. (See also my detailed comparison document.)

I think it would be a great idea for us to continue those discussions publicly in this issue, though.

(@hax has said that their free time will be scarce over the next several months, which I will definitely try to respect with regards to advancing this proposal. ^_^)

Oct 27 '21 13:10 js-choi

The major differences seem to be the namespace, extraction, and special affordance for getters/setters. The former has strong pushback, the middle doesn't seem to have compelling motivation yet, and the latter doesn't seem to warrant special treatment (this is a combo of my opinion and my estimation of committee temperature).

Are there other differences I've missed?

Oct 27 '21 13:10 ljharb

@hax has said that they are open to dropping the special namespace (not sure about the special polymorphic extraction/calling syntaxes)—it’s the special treatment of getters/setters that’s the crux, perhaps.

Oct 27 '21 13:10 js-choi

i hope this make sense

import {map} from 'somewhere';

document.querySelectorAll('div')
|> []:filter(%, v => v.clientWidth > 200) // : to unThis 
:: []:filter(v => v.clientHeight > 200) // :: as alternative |> and %, RHS should be function and prepend LHS as first param
|> :map(%, v => (v.style.color="red", v)) // : to unThis 
:: :map(v => (v.style.backgroundColor="green", v)) 

// or using prototype
document.querySelectorAll('div')
|> Array.prototype:filter(%, v => v.clientWidth > 200) // : to unThis 
:: Array.prototype:filter(v => v.clientHeight > 200) // :: as alternative |> and %, RHS should be function and prepend LHS as first param

// maybe an alternate option can be
document.querySelectorAll('div')
|> Array.prototype:filter(%, v => v.style.color === "red") // : to unThis 
|> Array::filter(%, v => v.clientWidth > 200) // :: as shortcut for [CLASS].prototype:[METHOD]
:> Array::filter(v => v.clientHeight > 200) // :> as alternative |> and %, RHS should be function and prepend LHS as first param
:> :map(v => (v.style.backgroundColor="green", v))

in this way we can also divide this proposal in three operators : (unThis) :: (unThis from prototype) :> to prepend LHS value in RHS parameters

Nov 11 '21 07:11 nkitku

Thanks for the comment, although it doesn’t seem to be related to the extensions proposal (the original topic of this issue).

I’m going to mark both of our comments as off-topic. You could open a new issue about this idea. ^_^

(For what it’s worth, TC39 is trying to minimize the number of operators that get added to the language, so it is unlikely that TC39 would add three new operators in addition to the Hack pipe operator. In addition, an unThis operator would lose the natural word order that a bind operator would restore. So I don’t think we would pursue your idea anyway—thanks anyway, though!)

Nov 12 '21 01:11 js-choi

As the extensions section (and the in-depth comparison) say, the concrete differences between bind-this and extensions are currently:

Bind-this has no special variable namespace (but @hax is willing to drop this).
Bind-this has no implicit syntactic handling of property accessors.
Bind-this has no polymorphic const ::{ … } from …; syntax.
Bind-this has no polymorphic …::…:… syntax.
Bind-this has no Symbol.extension metaprogramming system.

@hax is willing to drop the first difference, but I’m not yet sure whether he would be willing to drop anything else from the list above. But I plan to keep engaging with him over the next few months, time permitting.

Nov 12 '21 01:11 js-choi

An update: I, @tabatkins, and @hax recently wrote articles about the dataflow proposals, including bind-this and Extensions, and TC39 also held two two meetings about the dataflow proposals:

We will discuss the two proposals further at the next plenary at the end of this month.

Mar 18 '22 19:03 js-choi

Note, as the recent change from bind-this to call-this, the semantic of this proposal is now the subset of extensions proposal, and the syntax of this proposal also could be compatible with extensions proposal, if we choose "receiver-first style (bracketed)" like rec::[fn](arg0). ( :: is bikeshed, if we choose ->, it would be rec->[fn](arg0). )

Mar 29 '22 15:03 hax

I must say I really dislike the bracketed syntax. Using parenthesis (rec::(getFn())(arg0)) should be allowed, but not required for identifiers (rec::fn(arg0)) and member expressions (rec::namespace.fn(arg0), rec::namespace["fn"](arg0)).

Mar 29 '22 17:03 bergus

@bergus As extensions proposal, it also have rec::method() syntax so the pair of rec::method() and rec::[method]() is actually mapping the rec.method() and rec[method]() syntax.

Mar 29 '22 17:03 hax

See also https://github.com/tc39/proposal-call-this/issues/10#issuecomment-1082557270. At plenary, the Committee weakly preferred tight unbracketed receiver-first syntax.

Mar 29 '22 18:03 js-choi

@hax Are you referring to this thing? I don't quite understand why rec::[method]() uses bracket syntax - it doesn't appear to evaluate method to a property name. I think it would make sense in rec::namespace:[nameExpr](...args), desugaring to Call(GetOwnProperty(namespace, nameExpr).value, rec, args) (or GetExtension instead of GetOwnProperty), but not without a namespace object in which the property name is resolved (since we don't want to resolve it on the receiver).

Mar 30 '22 00:03 bergus

@bergus Yes. v::ns:[expr] is also possible, or required if we have strong symbol use cases (see https://github.com/tc39/proposal-extensions/issues/11).

Syntax rec::method / rec::[method] choose [] is just for matching v.method / v[method]. But you are right, rec::[method] doesn't evaluate method to key but evaluate method to the method (or accessor) directly.

Of coz, we could consider other brackets syntax if we want to keep [x] alway mean evaluating key: rec::(method), rec::{method}, rec::${method} (pattern match proposal use syntax like that) or even rec::<method> (turbofish! 😂 ), it's just like the current escape hatch syntax of decorators @(decorator).

May 24 '22 03:05 hax

Syntax rec::method / rec::[method] choose [] is just for matching v.method / v[method]. But you are right, rec::[method] doesn't evaluate method to key but evaluate method to the method (or accessor) directly.

(For what it’s worth, I actually see some value in an analogy of bound functions acting as pseudo-“methods” of their objects, with the original functions acting as pseudo-“keys”. For example, in rec::fn(), the fn would be acting like a “key” on the “method” rec::fn, before being called. However, I got some pushback from some others in the Committee about this analogy, so I dropped my pushing it.)

Jul 10 '22 16:07 js-choi

@js-choi I think the problem may be "bound" is unrelated semantic (of method), and I'm not sure the pushback is because such analogy, my impression is some delegates don't like "free" method. Actually I also feel "free" methods are not common in JS ecosystem, this is why extensions have a special syntax constraints to make it not as "free" as normal functions, one of my design goal is to make the extension users can only use extension methods as "method", not "function" by default.

Jul 11 '22 10:07 hax