A big problem is also that semantically keys and values are very different
in maps, in that keys are unique and values aren't. Inverting a map could
cause problems if you don't take that into account. Of course, if you use
the Map.new/2 solution the problem is there anyways, but at least you're
being explicit in what happens.
Only one use case has been presented and I think I would need at the very
least a few more before considering whether this belongs in core. When a
function is this small and the use cases are rare and specific, I think
implementing it in your own code usually works best.
On Wed, 6 Feb 2019 at 23:36, Ben Wilson <benwilson...@gmail.com> wrote:
> Map.invert is at least largely harmless, unlike some of the other
> proposals that happen. It's still a little odd to me to have a function
> that boils down to just:
>
> Map.new(map, fn {k, v} -> {v, k} end)
>
> Honestly that is almost clearer if you've never heard the word "invert"
> with respect to maps.
>
> On Wednesday, February 6, 2019 at 1:35:49 AM UTC-5, Justin Gamble wrote:
>>
>> Hi,
>>
>> I think an invert() method on Map would be convenient to use. It is only
>> a handful of lines of code to add to a custom program, but why should users
>> need to do that? In my opinion this basic functionality should be
>> implemented by the Map module.
>>
>> The invert() method would operate the same way it does for Ruby:
>> https://ruby-doc.org/core-2.2.2/Hash.html#method-i-invert
>>
>> Recently I wanted to invert a map in one of my Elixir programs (details
>> below), and I googled and found the below solution by Chris McCord in h
>> ttps://stackoverflow.com/questions/26614682/how-to-change-all-the-values-in-an-elixir-map
>> :
>>
>> def invert(map) when is_map(map) do
>> for {k, v} <- map, into: %{}, do: {v, k}
>> end
>>
>> I would basically like the above function to be added to the Elixir.Map
>> module.
>>
>> Here is the scenario for which I wanted to use this the invert function:
>>
>> *My Elixir program is synchronizing Robot Framework source code files
>> with TestRail. Robot Framework defines automated test cases. TestRail is
>> a web-based Test Case Management system. The goal is to synchronize
>> TestRail to contain all the tests that are defined in the Robot Framework
>> files, and in the same directory structure.*
>>
>> *Originally the Elixir program was specified to only create test cases in
>> TestRail. When you are creating a test case, the TestRail API
>> <http://docs.gurock.com/testrail-api2/reference-cases#add_case> requires
>> you to specify the ID of the directory (aka "section") where the case is
>> written. For this I use an Elixir Map to map paths to section IDs. When I
>> want to create a file in directory "/path/to/test.robot", then I Lookup the
>> section ID from my map & then call the "add_case" TestRail API function.*
>>
>> *That version of the program was a success. My boss was impressed and
>> next asked for enhancements to the program. The new functionality being
>> requested is to have existing TestRail Test Cases get updated with the
>> latest test steps defined in Robot Framework. Part of that update is to
>> verify that the path to the test case is the same in the Robot Framework
>> source code and in the TestRail. In this case we first call the TestRail
>> API to lookup a test case, at which point we know the section ID that it
>> belongs to. But we need to translate that to a directory path and confirm
>> that this path is the same location as where the test file exists in the
>> Robot Framework source code. *
>>
>> *For updating, it makes sense to also be able to use an Elixir Map to map
>> from the Section ID back to the Path -- the inverse of the original map. *
>>
>> *It is true that I could iterate through the original map until I found
>> the section ID in the value section, and then return the map index. But
>> that seems awfully inefficient when you consider that there are hundreds of
>> test files and thousands of tests. So I decided an inverse map would
>> provide faster lookup, at the cost of more memory being used. Also note
>> that in my scenario both the indexes and the values are unique; it is a
>> 1-to-1 mapping.*
>>
>>
>> This is just one example scenario. I imagine other examples exist, or
>> else the invert() function would never have been created in the Ruby
>> community.
>>
>> --
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/745bf765-c4b8-494e-9ded-7d1a50c05c5e%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/745bf765-c4b8-494e-9ded-7d1a50c05c5e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Andrea Leopardi
an.leopa...@gmail.com
--
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2B%2B5z%3DzTc1igwDiUFDOOWkN0Q9Rm2UgKUuBwWk%2Bby7T%3D7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
