I'm really liking the proposal too. About the naming problem, my considerations:
- I agree with Matt when he says `pipe_to` makes sense, but it feels like it describes more of a use case then what the function does - `call`, `execute`, `run` and `apply` look like they would take a function as the first argument, not the args. You can refer to plain english to get my reasoning: "to `call`/`execute`/`run`/`apply` the `function` with/to some `args`" - `apply` by itself has another downside, because there is already `Kernel.apply`, which does basically what we need, but with the reverse argument order - `send` could generate confusion because there is already `Kernel.send`, but so far for me, that's one of the best options - `dispatch` is not very commonly used name, but that's not a very strong argument IMO, tied with `send` as the best option So, I'm pro calling it `send` or `dispatch` because they correctly describe the function, not just an use case, and they are semantically correct: "to `send` or `dispatch` the `args` to the `function`" Something that came to my mind is that we could have both options: `Function.send(args, function)` and `Function.dispatch(first_arg, function)`. That way, with `[1, 2] |> Function.send(&Kernel.+/2)`, would be possible to add multiple args functions to pipes (not really readable, but interesting technique IMO). WDYT? On Friday, August 16, 2019 at 12:31:40 PM UTC-3, Matt Baker wrote: > > I like this proposal. > > - It doesn't add any new syntax constructs or special cases to the > language, correct? I know opinions vary, but I think this is a strength of > the proposal. > - To me "&1" happens to also serve as a convenient visual indicator of > "where the value's gonna go." It's subjective, but for me it's just as > effective as the idea of using "_" that some people have mentioned, while > not changing or adding to the meaning of "_". > - I found it quite intuitive > - I also found it more clear than the existing (&foo..).() I see > today. I've never written code this way and found it a little odd to read > at first, but have since seen in in other code bases. > > My only quibble is the name. pipe_to makes sense, but it also feels like > it describes the use case more than describing what the function does. Am I > correct in thinking this simply takes the first argument and passes it to > the function capture on the right when it executes it? > > A few of these have been floated already, but words that come to mind... > > - Function.call > - Function.execute > - Function.run > - Function.dispatch > - Function.apply > - Function.send > > All that said, I'd hate to see naming alone get in the way of the > proposal, I'm in favor of it even as is. > > On Friday, August 9, 2019 at 7:28:25 AM UTC-7, José Valim wrote: >> >> Hi everyone, >> >> With the addition of Function.identity/1, I would like to propose another >> function to the Function module: pipe_to/2. >> >> The idea is that instead of: >> >> "foo >> |> String.upcase() >> |> (&Regex.scan(~r/foo/, &1)).() >> >> One can do: >> >> "foo >> |> String.upcase() >> |> Function.pipe_to(&Regex.scan(~r/foo/, &1)) >> >> Or if you import it before: >> >> "foo >> |> String.upcase() >> |> pipe_to(&Regex.scan(~r/foo/, &1)) >> >> While I wouldn't write the "pipe to anonymous" code, I have seen enough >> code in the wild that uses it that having a more readable (albeit more >> verbose) approach in the language sounds reasonable to me. The >> implementation can be inlined by the compiler to avoid the extra dispatch >> cost. >> >> What are your thoughts? If you "pipe to anonymous functions" in your code >> today, would you prefer to use the new function? Yes/no? Why? >> >> Thank you, >> >> *José Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Director of R&D >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/01b6fe4b-8a83-4a84-9675-55f3c7ccb642%40googlegroups.com.
