Feature #18821
open
Expose Pattern Matching interfaces in core classes
Description
Problem Statement¶
Pattern matching is an exceptionally powerful feature in modern versions of Ruby, but it has one critical weakness that we should discuss:
It is only as powerful as the number of classes which implement its interfaces.
The more common these interfaces become, the more powerful pattern matching will become for everyday use in any scenario.
Areas of Attention¶
That said, what are some classes in core Ruby where it may make sense to implement pattern matching interfaces, and what do we gain from them? I will provide an abbreviated list, but can look to qualify a larger list of potentials if this is of interest.
Set¶
Currently Set does not implement deconstruct. Especially Enumerable-like and Array like entities make sense here:
# Hypothetical implementation
class Set
alias_method :deconstruct, :to_a
end
Set[1, 2, 3] in [1, 2, *]
# => true
Matrix¶
Speaking of Array-like structures, Matrix may make sense as well:
class Matrix
alias_method :deconstruct, :to_a
end
# => :deconstruct
Matrix[[25, 93], [-1, 66]] in [[20..30, _], [..0, _]]
# => true
CSV¶
In the case of headers especially this can become very powerful with deconstruct_keys:
require "csv"
require "net/http"
require "json"
# Hypothetical implementation
class CSV::Row
def deconstruct_keys(keys)
# Symbol/String is contentious, yes, I will address in a moment
self.to_h.transform_keys(&:to_sym)
end
end
# Creating some sample data for example:
json_data = URI("https://jsonplaceholder.typicode.com/todos")
.then { Net::HTTP.get(_1) }
.then { JSON.parse(_1, symbolize_names: true) }
headers = json_data.first.keys
rows = json_data.map(&:values)
# Yes yes, hacky
csv_data = CSV.generate do |csv|
csv << headers
rows.each { csv << _1 }
end.then { CSV.parse(_1, headers: true) }
# But can provide very interesting results:
csv_data.select { _1 in userId: "1", completed: "true" }.size
# => 11
Though this one does raise the broader question of the conflation of Symbol and String keys for our convenience. Given that Ruby has a habit of coercing between the two in other cases I do not find this to be against the spirit of Ruby.
RegExp MatchData¶
In a similar line of thinking to the CSV I believe this would present interesting opportunities, though does raise the question of what to do with nil types (perhaps return [] and {} respectively? May be hacky though)
class MatchData
alias_method :deconstruct, :to_a
def deconstruct_keys(keys)
named_captures.transform_keys(&:to_sym).slice(*keys)
end
end
IP_REGEX = /
(?<first_octet>\d{1,3})\.
(?<second_octet>\d{1,3})\.
(?<third_octet>\d{1,3})\.
(?<fourth_octet>\d{1,3})
/x
'192.168.1.1'.match(IP_REGEX) in {
first_octet: '198',
fourth_octet: '1'
}
# => true
As with before though, we do risk setting a precedent on the conflation of Symbol and String keys when it is convenient to us, so may be worth proceeding with caution there.
OpenStruct¶
Much like Struct I believe there's a good case to make here:
class OpenStruct
def deconstruct_keys(keys) = keys ? to_h.slice(*keys) : to_h
end
me = OpenStruct.new(name: 'Brandon', age: 31)
me in { name: /^B/ }
# => true
Other Thoughts¶
I believe there is great potential in the core of Ruby to spread the pattern matching interface. The more common it becomes the more useful it will be to users.
Especially if this were to be adopted into places like Rack, Net::HTTP, JSON, and other areas where frequently more imperative deconstructions and querying are already commonly used.
I bring this up, rather than opening PRs, as I would like to see whether or not the core Ruby team is interested in these types of PRs and work of finding where else these interfaces may make sense.
If you would like my more complete thoughts on this, and considerations for pattern matching interfaces in Ruby, I had written Pattern Matching Interfaces in Ruby some time ago to note concerns, potential guidelines, and other considerations.
Updated by 
Updated by 
Updated by 
Updated by