A bit. The funny thing, though, is that it of course makes it
possible to do either – so the irregularity actually provides a kind
of resilience. The consistent version, should it ever come into
being, will shut the door on one of them.
I know that people don’t want to do select { not } and so on… so
I can see that it’s not really ideal. But it’s kind of fascinating
that “fixing” it, in either direction, would result in a net loss of
functionality.
overridden when it shouldn’t have been.
A bit. The funny thing, though, is that it of course makes it
possible to do either – so the irregularity actually provides a kind
of resilience. The consistent version, should it ever come into
being, will shut the door on one of them.
I know that people don’t want to do select { not } and so on… so
I can see that it’s not really ideal. But it’s kind of fascinating
that “fixing” it, in either direction, would result in a net loss of
functionality.
Avoiding net loss, how about going for gross gain. So how about “fixing
it” so there is both?
select
select_pair
And {meth}_pair could also work for assoc arrays too.
Returns a new array that is a one-dimensional flattening of this
array (recursively). That is, for every element that is an array,
extract its elements into the new array. If the optional _level_
argument determins the level of recursion to flatten.
Returns a new array that is a one-dimensional flattening of this
array (recursively). That is, for every element that is an array,
extract its elements into the new array. If the optional _level_
argument determins the level of recursion to flatten.
Cool! I actually didn’t know that had made it into 1.9. I look
forward to retiring flattenx
Seems like a good name for a good method.
hmm… in Facets, Hash#slice is just an alias for Hash#values_at. #slice is a reasonably good name. however I suggested #select_pair, not
as a name for #pairs_at, but as a hash equivalent of #select, to enrich
the langauge with greater polymorphism between hash and asscocivtive
arrays.
Extract a hash out of this hash, that only contains key-value pairs
matching patterns and return it. patterns can be for example
/^foo/
to extract ‘foobar’ and ‘foobaz’ or ‘foo’/:foo to extract ‘foo’.
def extract(*patterns)
patterns.map! { |pat| pat.respond_to?(:match) ? pat : pat.to_s }
result = default_proc ? self.class.new(&default_proc) :
self.class.new(default)
each { |k, v| result[k] = v if patterns.any? { |pat| pat === k.to_s
} }
result
end
end
class ::Hash
include HashInclusion
end
The duck typing is a bit fishy, but it’s possible to add pattern
objects, that implement #=== and #match this way. Coincidently this is
the case for Regex instances.
It’s also interesting, that it’s quite difficult to create an empty
“copy” of a given hash in Ruby, without duping and clearing it.
overridden when it shouldn’t have been.
A bit. The funny thing, though, is that it of course makes it
possible to do either – so the irregularity actually provides a kind
of resilience. The consistent version, should it ever come into
being, will shut the door on one of them.
I know that people don’t want to do select { not } and so on… so
I can see that it’s not really ideal. But it’s kind of fascinating
that “fixing” it, in either direction, would result in a net loss of
functionality.
No it wouldn’t because you could just call .to_a on the returned hash to
get the nested array representation.
In addition to being Enumerables themselves, arrays serve as the
to do it for Hash.reject. Or, if you are of the belief that indeed
=> [[1, 3]]
No it wouldn’t because you could just call .to_a on the returned hash to
get the nested array representation.
that’s a good point.
the downside however is that we would always have to use #to_a to
ensure polymorphism between assoc array and hash. so it’s a bit of an
anti-duck. (array doesn’t have a reciporcal #to_h either btw, though
that would be nice in itself!)
