Any other thoughts on this? I'd like to continue the discussion or move forward with a decision to include or not include something like IO.inspect with an :apply option. I'm very open to changes in the name of the option, but the general functionality of a function that can transform the item to be inspected, but still returning the original input. This is something that I feel would be very helpful in debugging use-cases.
On Friday, January 19, 2018 at 8:43:17 AM UTC-8, [email protected] wrote: > > `apply` is succinct and clear. I created a PR here: > https://github.com/elixir-lang/elixir/pull/7229 > > It's been closed for now, until something (if anything) is agreed upon. > > Are there downsides of adding `apply` to IO.inspect/3 that outweigh the > benefits? > > On Monday, January 15, 2018 at 1:14:54 PM UTC-8, Martin Svalin wrote: >> >> `map` would have the connotation of applying a function to all elements >> of a collection. `apply` would more directly have the connotation of >> running a function with some arguments. >> >> `IO.inspect(value, apply: &length/1)` >> >> I like the idea of being able to narrow down what I'm inspecting during >> the print-debugging workflow I inevitably regress to. `nested_structure |> >> IO.inspect(apply: & get_in(&1, [:foo, :bar, :baz]))`. Thumbs up for the >> idea. >> >> mån 15 jan. 2018 kl 17:31 skrev Marcus Gartner <[email protected]>: >> >>> Doh! I should have realized the issue with executing the function >>> passed. >>> >>> I like the idea of a transform option that can be passed. >>> >>> IO.map makes sense in my example, but wouldn't make sense to me if the >>> pipeline wasn't dealing with an enumerable, and it would be nice if this >>> feature was general enough to work idiomatically with any possible values. >>> >>> On Sat, Jan 13, 2018 at 7:38 PM OvermindDL1 <[email protected]> wrote: >>> >>>> Or call it `map` as it's shorter and perfectly descriptive. I've made >>>> a few variants of this myself and I'd love it built into IO.inspect. >>>> >>>> On Jan 12, 2018 16:31, "Greg Vaughn" <[email protected]> wrote: >>>> >>>>> I like the original idea and would like to suggest another approach. >>>>> What if there were an additional Inspect.Opts of :transform? It then >>>>> would >>>>> enable this sort of thing: >>>>> >>>>> ["thing1", "thing2"] >>>>> |> generate_more_things() >>>>> |> IO.inspect(transform: &length/1) >>>>> |> do_something_with_things() >>>>> >>>>> -Greg Vaughn >>>>> >>>>> > On Jan 12, 2018, at 5:18 PM, José Valim <[email protected]> wrote: >>>>> > >>>>> > Thanks for the proposal! >>>>> > >>>>> > Unfortunately that would make us unable to inspect functions >>>>> themselves, which is a valid argument to IO.inspect after all. >>>>> > >>>>> > Imagine the confusion of trying to inspect a pipeline that may emit >>>>> an anonymous function only to find it is being executed instead. >>>>> > >>>>> > >>>>> > >>>>> > José Valim >>>>> > www.plataformatec.com.br >>>>> > Founder and Director of R&D >>>>> > >>>>> > On Fri, Jan 12, 2018 at 10:59 PM, <[email protected]> wrote: >>>>> > I often find myself wanting to inspect things in the middle of a >>>>> chain of pipes, but I don’t always want to inspect the return values >>>>> as-is. >>>>> Sometimes I want to inspect sub-attributes or call functions on the >>>>> return >>>>> values to inspect them. >>>>> > >>>>> > For example, imagine the contrived pipeline below. >>>>> > >>>>> > ["thing1", "thing2"] >>>>> > |> generate_more_things() >>>>> > |> do_something_with_things() >>>>> > >>>>> > If I want to know the length of the list returned by >>>>> generate_more_things/1, I would do this: >>>>> > >>>>> > ["thing1", "thing2"] >>>>> > |> generate_more_things() >>>>> > |> (fn things -> >>>>> > things |> length() |> IO.inspect() >>>>> > things >>>>> > end).() >>>>> > |> do_something_with_things() >>>>> > >>>>> > If IO.inspect can take a function as an argument, print the >>>>> inspection of the result of calling that function, but still return the >>>>> un-altered input, I could do this: >>>>> > >>>>> > ["thing1", "thing2"] >>>>> > |> generate_more_things() >>>>> > |> IO.inspect(fn things -> length(things) end) >>>>> > |> do_something_with_things() >>>>> > >>>>> > Or even: >>>>> > >>>>> > ["thing1", "thing2"] >>>>> > |> generate_more_things() >>>>> > |> IO.inspect(&length/1) >>>>> > |> do_something_with_things() >>>>> > >>>>> > I think this would aid during debugging and be a useful feature in >>>>> the standard library. I'd love to implement and contribute on this, but I >>>>> wanted to see if such a thing would be accepted before beginning work. >>>>> > >>>>> > Open to feedback! >>>>> > >>>>> > -- >>>>> > 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/4e2bfad0-b745-4059-8736-996e641c7bb2%40googlegroups.com >>>>> . >>>>> > For more options, visit https://groups.google.com/d/optout. >>>>> > >>>>> > >>>>> > -- >>>>> > 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/CAGnRm4KAvw%2BwWnh7d60%3DvKEkuLvWfyoh4XuM9rbuxz_CaLg9%3DA%40mail.gmail.com >>>>> . >>>>> > For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>> 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/6CF01F3F-5848-4E19-BCA1-9D256824D6E0%40gmail.com >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> >>> You received this message because you are subscribed to a topic in the >>>> Google Groups "elixir-lang-core" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/elixir-lang-core/TUkmNHI4IbI/unsubscribe >>>> . >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>> >>> >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/CAJhqboH_tYYRPFWf8HuVJru5phmOmU7tK_PDWVca36mUfWhJ8Q%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAJhqboH_tYYRPFWf8HuVJru5phmOmU7tK_PDWVca36mUfWhJ8Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> 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/CAONCvEwH7a8GzHtQb78gGo0H95BJVxq8KPAcvGy3cZKYXr9nGA%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAONCvEwH7a8GzHtQb78gGo0H95BJVxq8KPAcvGy3cZKYXr9nGA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- 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/29087b37-89f9-4bf8-a77c-f471a1a11613%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
