17:46 | <TabAtkins> | Sigh, everyone keeps talking past each other, assuming only their own use-cases exist. Justin Ridgewell has said several times, flat-out, that they'd like to use the bind-this operator to produce "fluent API" libraries that are slightly more ergonomic than what pipe can do. |
17:46 | <TabAtkins> | If you're talking instead just about the call-this operator, then yes, it won't cause schism, for the reasons I already gave. |
18:59 | <ljharb> | ah, i guess I’d missed that |
23:09 | <sarahghp> | I wonder if space was made to discuss the more general question bringing up the use cases people imagine explicitly might make it easier to think about the proposals more broadly. |
23:10 | <sarahghp> | Overall though, this diagram and write-up are so interesting. I do have to say I'm a big pipe op fan and somewhat dubious about the others. Writing free-this functions seems like a big risk in terms of ecosystem bifurcation. |
23:10 | <sarahghp> | Elaborating ways to use I also personally, but maybe only me, worry about PFA quite a lot. It's such a fundamental shift to decouple argument order with the order in which they are provided and I'm not certain there are use cases that aren't achievable by other means / are so common that they are worth the syntax cost / inscrutability trade-off. Even the example of memoizing and expensive operations could be addressed with |
23:11 | <sarahghp> | Also, I think the example in Tab's gist is slightly incorrect, right? fn~(arg0, ?, arg2, ?) becomes (a)=>fn(arg0, a, arg2, a) and fn~(arg0, ?1, arg2, ?2) would be (a,b)=>fn(arg0, a, arg2, b) . |
23:11 | <sarahghp> | Anyways, this is suddenly a lot of thoughts. I should probably write a gist too, 😆 |