Open baweaver opened 2 years ago
Users can use header_converters: :symbol
:
require "csv"
data = CSV.parse(<<~ROWS, headers: true, header_converters: :symbol)
Name,Department,Salary
Bob,Engineering,1000
Jane,Sales,2000
John,Management,5000
ROWS
pp data.select { _1 in name: /^J/ }
[#<CSV::Row name:"Jane" department:"Sales" salary:"2000">,
#<CSV::Row name:"John" department:"Management" salary:"5000">]
There's an assumption made in the pattern matching code which will make it very hard to use, and that's the presumption of
Symbol
keys onCSV::Row
.If you were to make a PM interface and look at the keys:
You will receive
Symbol
keys. Why is this a problem? Because if you are loading CSV data it will most likely be from a file orString
which we can take directly from the documentation:If we were to test this against pattern matching (and adding a
keys
debugging statement):As it exists today this feature cannot be used except for manually created data like in the tests which will not be the experience of end users who either parse from a
String
orFile
.I would like to propose that we modify the method to treat the keys as keyword arguments, rather than as
Symbol
s, which will allow this feature to be used for common usecases:This does, in a sense, conflate
Symbol
andString
keys, butString
keys are impossible in pattern matching:So the options are either have an interface which will only work with test data and users who manually create
Symbol
keys (which is a minority case), or consider a keyword-like approach that can handle the ambiguity of keys types.I believe this is a reasonable assumption of coercion to make, as Ruby has done this in other cases with converting between
Symbol
andString
whenever it is considered reasonable input from the user. I believe this would qualify as reasonable user input.If this is of interest I can submit a PR, but wanted to run the idea by people first.