Pipeline Champions
2022-01-26
plaintext logs
prev next
source on github
20:01
<TabAtkins>
jschoi: You've been doing quite well here; thank you for the talk so far.
21:16
<yulia>
yo
21:16
<yulia>
so, 1 https://matrix.to/#/!RKGOsXKqdKdyWOiTEA:matrix.org/$Xqf1VcaFHqzkIFLl6JerBlMhHS5e1SuAxxqBSvv-HkQ?via=matrix.org&via=mozilla.org&via=igalia.com
21:17
<yulia>
regarding this, I was thinking of this as how this overlaps with the pipeline operaor
21:17
<yulia>
but, i figured, that there had been discussion about this and there was a reason to exclude it
21:17
<yulia>
if this is intended then the overlap betweeen pipeline and bind should have been much larger
21:18
<yulia>
however, i would say that if we have both, it is reasonable to say that bind this cannot be chained
21:19
<yulia>
or some other restriction
21:19
<ljharb>
re bind-this: it is very important that there's a way to do array <operator> slice without needing slice to exist on array.
21:19
<TabAtkins>
Yes, this overlap has been discussed, and is one of the reasons I don't want bind-this (and wrote call-this in the way I did)
21:19
<ljharb>
the word order being critical there.
21:19
<yulia>
Yes, this overlap has been discussed, and is one of the reasons I don't want bind-this (and wrote call-this in the way I did)
yeah, i would accept that
21:19
<yulia>
re bind-this: it is very important that there's a way to do array <operator> slice without needing slice to exist on array.
agreed
21:20
<TabAtkins>
If word order is important, then it's unavoidable that we will have libraries explicitly written to allow "method-chaining"-ish (aka "fluent API") calling, using the operator.
21:20
<ljharb>
that's fine
21:20
<ljharb>
people do terrible things with Proxy, predominantly
21:20
<yulia>
i don't think we have a disagreement on this
21:20
<ljharb>
but the intended use case still needs them
21:20
<ljharb>
our job is explicitly not to be paternalistic
21:20
<ljharb>
if people want to do gross things, we have to let them (in some ways)
21:20
<TabAtkins>
If word order is less important, then call-this allows that functionality in a terse and reliable fashion, without encouraging such a library design pattern.
21:21
<ljharb>
word order is very important
21:21
<TabAtkins>
Our job is absolutley to predict how things will affect the ecosystem and avoid things that we believe will likely be bad.
21:21
<ljharb>
syntax sugar that just replaces .call doesn't hold its own weight imo
21:21
<ljharb>
it's to predict that, but that doesn't mean we can stop everyone from doing bad things
21:21
<yulia>
i think word order depends on it's context. it is an improvement in some cases
21:21
<ljharb>
we can't stop ASI either
21:22
<ljharb>
i'm certainly all for minimizing misuse, especially when it reduces burden on eslint
21:22
<jschoi>
I think you think word order is important but that word order can be solved by combining the pipe operator with call-this. That’s correct, right?
21:22
<TabAtkins>
"we can't stop bad things" doesn't mean we give up on the concept of things being bad as a reason to avoid something; no need to slippery-slope this.
21:22
<ljharb>
sure
21:22
<ljharb>
but it also doesn't mean "people will do bad things" is sufficient reason to block something
21:22
<ljharb>
it's somewhere in the middle
21:22
<TabAtkins>
jschoi: Yes, obj |> slice@(#, 0, 2) kinda works
21:22
<jschoi>
This is a good point. f(x) and x |> f(#) are both good at various times.
21:23
<jschoi>
Sometimes you want verb first; sometimes you want noun first.
21:23
<yulia>
yes
21:23
<Justin Ridgewell>
I don't understand why call-this is taken as a viable alternative to bind-op.
21:23
<Justin Ridgewell>
It's the less fluent choice, because we don't want to promote a code style.
21:23
<ljharb>
let me state my opinion more strongly: muggles (devs who aren't deep into language minutiae) will never prefer writing functions that use this solely because they can use it with ::
21:24
<ljharb>
it just won't happen
21:24
<ljharb>
certainly some rebels will try to do something terrible and clever with that approach! but that doesn't mean it'll go anywhere
21:25
<yulia>
i've seen a whole lot of bind and call
21:25
<yulia>
and a lot of people being like "why is this not the this that it was called on"
21:25
<jschoi>
jschoi: Yes, obj |> slice@(#, 0, 2) kinda works
obj |> slice@(#, 0, 2) arguably works as well as obj |> slice(#, 0, 2) works.
21:26
<TabAtkins>
Yes it does, it's just admittedly clearly worse than obj::slice(0, 2)
21:26
<ljharb>
right
21:26
<yulia>
yep
21:26
<ljharb>
i hope we can all agree that all three forms are better than status quo
21:26
<ljharb>
and that the third is better than the other two, looking at it in isolation
21:26
<ljharb>
(better, for this use case)
21:26
<yulia>
i believe we do have the problem pipeline solves: functional chaining. We do have a problem with binding
21:26
<yulia>
oh, i think i misread
21:27
<yulia>
i would rather have obj::slice.
21:27
<Justin Ridgewell>
By function chaining, do you mean nested functions or method chaining?
21:28
<Justin Ridgewell>
I think we will continue to have method chaining (including patching onto the global prototypes) as long as we do not have a bind-op.
21:28
<sarahghp>
I would rather not have :: at all
21:28
<Justin Ridgewell>
Pipeline will solve some of it, but the explicit topic token will always be less fluent than a regular method chain.
21:28
<Justin Ridgewell>
So we will continue to see method chaining regarless.
21:28
<ljharb>

i mean given

arr
  .slice(…)
  .flat(…)
  ::somethingNew(…)
  .filter(…)

vs

arr
  .slice(…)
  .flat(…)
  |> somethingNew@(#, …)
  .filter(…)

the former is clearly better to me.

21:28
<pokute>
Is arrayLike |> Array.slice@(#, 0, 2) valid?
21:29
<sarahghp>
I think both of those are undesirable, honestly
21:29
<TabAtkins>
Justin Ridgewell: So, right, call-this is intentionally not as "fluent" as bind-this in the .call() case, specifically to avoid overlapping with pipeline. It achieves the functionality (terse, reliable .call()) without anything else. Self-binding (aka method extraction) is imo best done by PFA; obj.method~() is clearly better than obj::obj.method, imo. Other-binding is the final leftover case, but I think this is (a) the least common of these cases, afaict from the collected data and (b) sufficiently okay to just use arrow functions with - that=>slice@(that, 0, 2) seems fine for this.
21:29
<ljharb>
pokute: Array.slice doesn't exist, but otherwise yes
21:29
<TabAtkins>
pokute: yes
21:29
<ljharb>
sarahghp: i do that exact pattern in a ton of libraries, i just break it up because i don't have a chaining affordance
21:29
<TabAtkins>
Well, sorry, Array.slice is undefined
21:29
<ljharb>
use Array.prototype.slice, and it works
21:29
<TabAtkins>
yeah
21:29
<TabAtkins>
Or [].slice
21:30
<Justin Ridgewell>
Next let's not have optional chaining, because we already have && and regular dot accses...
21:30
<sarahghp>
sarahghp: i do that exact pattern in a ton of libraries, i just break it up because i don't have a chaining affordance
If I were empress of a codebase (big if), I would definitely expect a single paradigm in a chain. If you want to pipeline, write it all as pipeline
21:30
<ljharb>
indeed, a lot of the arguments for optional chaining hold here
21:30
<ljharb>
sarahghp: right, but i wouldn't want to use pipeline. i'd want to use :: :-)
21:31
<sarahghp>
that's worse!
21:31
<ljharb>

but also,

arr
  |> #.slice(…)
  |> #.flat(…)
  |> somethingNew@(#, …)
  |> #.filter(…)

looks far worse to me than either of those

21:31
<ljharb>
which would be the "all pipeline" form
21:31
<sarahghp>
I don't want to ever explain to a beginner why sometimes :: and sometimes .
21:31
<ljharb>
you'd have to do that whether it's a chain or not (in a chunk of code that uses both)
21:31
<ljharb>
just like you have to explain . vs ?., now
21:32
<ljharb>
or .x vs ['x']
21:33
<sarahghp>
yes but I don't personally find the advantage to be worth adding another
21:33
<sarahghp>
you are absolutely not wrong, tho
21:34
<ljharb>
to be fair, i think that in most of my use cases, i'd probably use only :: and not . in a single chain, because i want all those method calls to be robust
21:35
<ljharb>
which means i'm comparing a normal OOP chain with ., converting to a more robust :: in place of every . - vs, converting to a more robust |> + fn@(#, in place of every ..
21:35
<ljharb>
and i'm quite certain the pipeline one would look horrendous
21:47
<pokute>
In my opinion, if someone goes through the trouble of setting a local variable like slice that they can use as a function, it's approximately as much effort to import it as an unbound function as it is to destructure it from Array.prototype (or []). For something like slice, I'd expect that some coders would use a bound version while others would use unbound since it's up to the user to choose which way to do it. Especially if this-calls are introduced after pipelines. For something like RxJs, it's different of course.
21:59
<pokute>
I haven't used call or bind other than a few times for React class components. When I've written pipelined code, I've used both [...] |> #.filter and [...].filter and did think of but ended up not adding [...] |> filter(#, ...) as an ergonomic alternative. For my style, [...]|> Array.filter(#, ...) (that I would add myself) feels more natural than just unspecific filter -function.
23:15
<yulia>
do you want me there?
23:15
<yulia>
(i could use a day off)
23:16
<jschoi>
do you want me there?
Completely optional, thanks and have a good day off!
23:16
<jschoi>
https://github.com/tc39/Reflector/issues/416
23:16
<yulia>
ah, i am @codehag if you wanna ping me
23:16
<yulia>
on most everything
23:16
<yulia>
except this
23:16
<yulia>
and my email
23:17
<yulia>
and a few other places ...
23:17
<jschoi>
Oh, yeah, I had forgotten, whoops.
23:18
<yulia>
np :D