Thank you for pointing out the chained 'select'!

Allow me to apologize for the incorrect problem statement.

The issue is actually not with downstream 'select's, but with other
calls that assume a hash-like behaviour on the part of the container.

Examples include Hash#[] and Hash#each_value.

Should I choose to use these calls somewhere, I need to first know
whether the container I have been passed is the original hash or the
result of at least one 'select'.

The matter is confusing since Hash#reject actually returns a hash!
Yes, Hash#reject is equivalent to Hash#delete_if on a 'dup' of self.
But, semantically, the exclusion filter on the hash is returning a
hash again, while the inclusion filter is not!

I hope this explains my question better.

Best regards,

JS

Pit Capitain wrote:
> Srinivas Jonnalagadda schrieb:
>> Enumerable#select always returns an array. On a hash too, it returns
>> an array of arrays of key-value pairs.
> 
> Right.
> 
>> The issue with this approach is that 'select' calls cannot be chained.
>> It is now mandatory to know whether the receiver is the original hash
>> or is the result of at least one 'select'.
> 
> It works for me:
> 
>   h = { 0 => 0, 1 => 2, 2 => 3, 4 => 4 }
> 
>   h.select { |k,v| k % 2 == 0 }.select { |k,v| v % 2 == 0 }
> 
>   # => [[0, 0], [4, 4]]
> 
> Can you show us your problem?
> 
> Regards,
> Pit