Feature #18773
opendeconstruct to receive a range
Description
Currently when you're pattern matching against a hash pattern, deconstruct_keys
receives the keys that are being matched. This is really useful for computing expensive hashes.
However, when you're pattern matching against an array pattern, you don't receive any information. So if the array is expensive to compute (for instance loading an array of database records), you have no way to bail out. It would be useful to receive a range signifying how many records the pattern is specifying. It would be used like the following:
class ActiveRecord::Relation
def deconstruct(range)
(loaded? || range.cover?(count)) ? records : nil
end
end
It needs to be a range and not just a number to handle cases where *
is used. You would use it like:
case Person.all
in []
"No records"
in [person]
"Only #{person.name}"
else
"Multiple people"
end
In this way, you wouldn't have to load the whole thing into memory to check if it pattern matched. The patch is here: https://github.com/ruby/ruby/pull/5905.
Updated by mame (Yusuke Endoh) 13 days ago
- Assignee set to ktsj (Kazuki Tsujimoto)
- Status changed from Open to Assigned
Updated by mame (Yusuke Endoh) 13 days ago
It would be easier to discuss if you could write a spec of what pattern match will pass what range. I understand as follows by reading your implementation. Right?
-
ary in [1, 2, 3]
will callary.deconstruct(3..3)
, which means "the length must be exactly 3" -
ary in [1, 2, *, 3]
will callary.deconstruct(3..)
, which means "the length must be greater than or equal to 3"
I understand your motivation, but I wonder if the spec could be more efficient. In the second calling sequence, the match requires only the first, second and last elements, but ary.deconstruct(3..)
needs to create an array including all elements because it does not know which elements are required.
Though the current implementation of pattern matching is not so efficient, but I am afraid that the proposed implementation looks very inefficient because it creates a Method object and calls #arity
.
Updated by ktsj (Kazuki Tsujimoto) 3 days ago
As a designer of pattern matching, I also understand your motivation.
However, I have the following concerns in addition to the ones mame pointed out.
- In the current implementation, when a pattern match fails in one-line pattern matching, the reason for the failure is displayed as an error message. I think it difficult to do the same thing by your proposal. (This feature is not a must, but it would be nice to have.)
$ ruby -e ‘[0] => []’
-e:1:in `<main>’: [0]: [0] length mismatch (given 1, expected 0) (NoMatchingPatternError)
- It might have a negative impact on performance. The current implementation caches the return value of
deconstruct
method, but this approach will no longer be available.