From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 1B51719C01E9 for ; Wed, 18 Nov 2015 07:43:32 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id AF13DB5D8AA for ; Wed, 18 Nov 2015 08:14:06 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id D1E6018CC7EA for ; Wed, 18 Nov 2015 08:14:06 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 569B512048A; Wed, 18 Nov 2015 08:14:05 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o2.heroku.sendgrid.net (o2.heroku.sendgrid.net [67.228.50.55]) by neon.ruby-lang.org (Postfix) with ESMTPS id F1E3B120462 for ; Wed, 18 Nov 2015 08:14:01 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=F96msqoLFG/WrixPI7nYSO85pZA=; b=t8CvPdbWfy96H0f7L4 j0bb3VvryFl9EjUp07kp8Cx6dt4QdKTkafX2FwO6p5fiMknrIQIkwkVeEmdVuOin dA6JDyKEptGCjOkpJtOCkdE908Q8hHEKZYahkKLcF04xj18qXyExw/3i2NsgBbDd PJFesC9+S8kLF3r/IZB7h/sHY= Received: by filter0474p1mdw1.sendgrid.net with SMTP id filter0474p1mdw1.20689.564BB4B462 2015-11-17 23:13:56.975164836 +0000 UTC Received: from herokuapp.com (ec2-50-16-126-45.compute-1.amazonaws.com [50.16.126.45]) by ismtpd0004p1iad1.sendgrid.net (SG) with ESMTP id 7h055D6WQCCvWYt6QEXnbA Tue, 17 Nov 2015 23:13:56.956 +0000 (UTC) Date: Tue, 17 Nov 2015 23:13:56 +0000 From: prijutme4ty@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Redmine-MailingListIntegration-Message-Ids: 46191 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 10984 X-Redmine-Issue-Author: olivierlacan X-Redmine-Issue-Assignee: akr X-Redmine-Sender: prijutme4ty X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4VTNoGpxovtXcorzQum3vrpuqnfc4bfn8Gzj JeO0vN+OmPgKhhdqPNSJz+jB6xDcpv1EohXNLb8yb89/bjInMFzaIsYnzt73f/TS/Cc3pbXqER4Zv+ 2hbS+yawiAncnNq72ku06psP4cd0YOn89tpi X-ML-Name: ruby-core X-Mail-Count: 71529 Subject: [ruby-core:71529] [Ruby trunk - Feature #10984] Hash#contain? to check whether hash contains other hash X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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/