Clarify relationship with robust method extraction

[js-choi]

See tc39/proposal-pipeline-operator#110 (comment), tc39/proposal-pipeline-operator#107 (comment), tc39/proposal-pipeline-operator#101 (comment).

I had forgotten that a discussion about robust method pre-extraction happened last September. By the time they returned to it in November, time was up. January was skipped while preparing for this, though @ljharb gave a comment about the importance of the prefix ::, as well as recently that it must be robust against delete Function.prototype.bind. ljharb/function.prototype.name gives examples of this pattern. There has been discussion of method-binding caching in tc39/proposal-bind-operator#46, in which a WeakMap is associated with each realm.

In any case, pipelines, including smart pipelines, and robust cached method pre-extraction can coexist. Using ljharb/function.prototype.name/implementation.js, line 19 as an example of useful coexistence:

return fn
|> &Function.prototype.toString
|> &String.prototype.match(#, classRegex)
|> !!#;

…which is just:

return !!&String.prototype.match(
  &Function.prototype.toString(fn),
  classRegex);

This security robustness is quite a different use case than simply wanting to express the callbacks in promise.then($ => console.log($)) more tersely, as well as the other goals of smart pipelines as well as the goals of other pipelines: most importantly, the untangled composition of expressions and calls.

I think secure cached method binding is out of scope for smart pipelines, even with Feature PF. It is also out of scope for @mAAdhaTTah’s Proposal-1 pipelines. These are orthogonal use cases. They cannot kill each other.

[js-choi]

console.log.bind(console) is not the same as (...$) => console.log(...$), when assigned to a variable rather than used inline.