[#71439] [Ruby trunk - Feature #11339] [PATCH] io.c: avoid kwarg parsing in C API — matz@...
Issue #11339 has been updated by Yukihiro Matsumoto.
7 messages
2015/11/11
[#71473] Re: [Ruby trunk - Feature #11339] [PATCH] io.c: avoid kwarg parsing in C API
— Eric Wong <normalperson@...>
2015/11/13
Entire series for sockets
[#71450] Ruby 2.3.0-preview1 Released — "NARUSE, Yui" <naruse@...>
Hi,
5 messages
2015/11/11
[#71617] [Ruby trunk - Feature #11664] [PATCH] introduce rb_autoload_value to replace rb_autoload — nobu@...
Issue #11664 has been updated by Nobuyoshi Nakada.
3 messages
2015/11/20
[#71721] [Ruby trunk - Feature #11741] Migrate Ruby to Git from Subversion — me@...
Issue #11741 has been updated by Jon Moss.
4 messages
2015/11/28
[ruby-core:71529] [Ruby trunk - Feature #10984] Hash#contain? to check whether hash contains other hash
From:
prijutme4ty@...
Date:
2015-11-17 23:13:56 UTC
List:
ruby-core #71529
Issue #10984 has been updated by Ilya Vorontsov.
Hello everyone.
I urge to remove Hash comparison methods and to stick to methods like `#contain`. Or at least to return `nil` instead of `false` for comparison of non-comparable hashes. Underlying reasons are strictly mathematical but have far-reaching consequences.
Usually we deal with linearly ordered sets or totally ordered (like usual numbers or string are) i.e. such sets that either `a <= b` or `b <= a` for every two elements `a` and `b` of a set.
Comparison can be generalized for posets or partially ordered sets. They don't require that any two elements are comparable. Set of hashes is a typical example of a partially ordered set (see "Partial ordered set" or "Hasse diagram" in wikipedia).
One must not implement `a <= b` for unrelated elements because if such comparison returns any certain result either true or false - then its negation would be counterintuitive. I'm not a proponent of current ruby approach of `Class#<=>` because ordinary intuition based on everyday use of totally ordered sets suggest that this code would be correct which is definitely false:
```ruby
if String <= Fixnum
puts 'String is a Fixnum subclass'
else
puts 'Fixnum is a String subclass'
end
```
But at least `String <=> Fixnum` is neither true or false but nil which allow us to distinguish such situations. `nil` result is properly handled by `Comparable` methods like `#sort`. Thus `[String, Fixnum].sort` will raise.
So why one can sort this array and which result does one expect?:
```ruby
[{}, {a:1,b:2}, {c:3}, {a:1}, {b:2}].sort
```
That's why, I insist, comparison of non-comparable hashes at least must return `nil`. As a more strict approach one can raise exception when try to compare hashes but it makes the main use-case impractical. But I can't see why one want to deal with such a controversial methods when `#contain` and `#included_by` will be enough for this not-so-often task.
As an example of why implementing `#<=>` for posets is not a good idea, lets consider this typical hand-written qsort implementation.
```ruby
def qsort(arr)
return arr if arr.size <= 1
pivot = arr[arr.length / 2]
left = arr.select{|el| el < pivot }
right = arr.select{|el| el > pivot }
central = arr.select{|el| el == pivot }
qsort(left) + central + qsort(right)
end
```
Okay. Now lets run and see how this "obvious" algorithm loses values.
```ruby
qsort( [{}, {a:1,b:2}, {c:3}, {a:1}, {b:2}] )
# => [{}, {:c=>3}]
```
Surely, sorting is already implemented, but this problem persist in every place where one suggest that `a < b`, `a == b` and `a > b` are the only possible alternatives - thus in almost every if-else pair.
I ask a community think one more time about consequences of such a decision.
Ilya
----------------------------------------
Feature #10984: Hash#contain? to check whether hash contains other hash
https://bugs.ruby-lang.org/issues/10984#change-54909
* Author: Olivier Lacan
* Status: Closed
* Priority: Normal
* Assignee: Akira Tanaka
----------------------------------------
Comparing hashes seems like a common practice but there currently isn't a method to ask a
hash instance whether it includes another hash instance.
The most intuitive method to reach for would be `Hash#include?` but it is in fact an alias to `Hash#has_key?`
What I'm looking for can be achieved with:
~~~
class Hash
def contain?(other)
self.merge(other) == self
end
end
~~~
Here's a simple demo of `#contain?` in use:
~~~
{ a: true, b: false }.contain?({ a: true})
# => true
{ a: true, b: false }.contain?({ b: false})
# => true
{ a: true, b: false }.contain?({ a: false})
# => false
{ a: true, b: false }.contain?({ c: true})
# => false
~~~
One important note is that this method is *not checking for nested hash matches*.
This may need to be addressed when the parameters include a nested hash perhaps.
Thanks to Terence Lee's help, nobu created a patch for this feature last year.
I've only modified the name of the method from [his original patch](https://gist.github.com/nobu/dfe8ba14a48fc949f2ed) and attached it to this issue.
---Files--------------------------------
Hash#contain_.patch (2.22 KB)
--
https://bugs.ruby-lang.org/