From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 83A171F463 for ; Fri, 27 Sep 2019 08:35:39 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id DBCE5120AB1; Fri, 27 Sep 2019 17:35:30 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 57F0C120AB1 for ; Fri, 27 Sep 2019 17:35:29 +0900 (JST) Received: by filter0077p3las1.sendgrid.net with SMTP id filter0077p3las1-25237-5D8DC9D5-1E 2019-09-27 08:35:33.389838982 +0000 UTC m=+308684.482612072 Received: from herokuapp.com (unknown [3.91.96.212]) by ismtpd0098p1iad2.sendgrid.net (SG) with ESMTP id zoWjsB69REOMoakNHb8fkA for ; Fri, 27 Sep 2019 08:35:33.220 +0000 (UTC) Date: Fri, 27 Sep 2019 08:35:33 +0000 (UTC) From: duerst@it.aoyama.ac.jp Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70682 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16183 X-Redmine-Issue-Author: zverok X-Redmine-Sender: duerst 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: =?us-ascii?Q?uQY=2F2xNrNfHHTWbKn6MBvvzfU5Pqk9I4lnOVb0CFDutyWS16W6HiSLqTvxDYaW?= =?us-ascii?Q?JQ1PmpJerVl28z821AvvvLxVIW2N6eNyeEwmQ5g?= =?us-ascii?Q?c3GEVmwI4IVLV0jY2iB4AvdV7OulmlNp33KMN+Y?= =?us-ascii?Q?KkhStnGVkJWdzUBIsgn=2F+4sFdoil3cqGVEB4j5k?= =?us-ascii?Q?WDxpyRQhW3ztIaPJeoxT9ssXb5lYtQHTVfQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95127 Subject: [ruby-core:95127] [Ruby master Feature#16183] Hash#with_default 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16183 has been updated by duerst (Martin D=FCrst). zverok (Victor Shepelev) wrote: > Eregon (Benoit Daloze) wrote: > > That means a copy of the Hash is necessary on each call to `#with_defau= lt`. > = > Yes, the same way it is for, say, `merge`, and we still use it in a lot o= f cases even when source hash would be dropped -- for the sake of chainabil= ity: Well, yes, but at least in my view, `merge` is a two-sided (symmetric) oper= ation. There are two hashes, and you merge them. It would be strange if one= of them is changed, but not the other. The fact that Ruby, because it's ob= ject-oriented, uses one of the hashes as a receiver is in first approximati= on just a syntax issue. Of course there are cases where `merge` is used in = a asymmetric way (your examples are all of this nature), but that's not the= original nature of `merge`. `with_default`, on the other hand, similar to the current methods that set = a default, is *by nature* asymmetric. Also, it's really rare (if such examp= les exist at all) that a new hash is needed because there's both a version = with a default and a version without a default. So adding the default in pl= ace and not making a copy seems to be the natural thing to do. I think that when you go through Ruby's builtin classes and standard librar= y, there are many case that can easily explained in similar terms. ---------------------------------------- Feature #16183: Hash#with_default https://bugs.ruby-lang.org/issues/16183#change-81762 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: = * Target version: = ---------------------------------------- Reasons: there is no way, currently, to *declaratively* define Hash with de= fault value (for example, to store it in constant, or use in an expression)= . Which leads to code more or less like this: ```ruby FONTS =3D { title: 'Arial', body: 'Times New Roman', blockquote: 'Tahoma' }.tap { |h| h.default =3D 'Courier' }.freeze # Grouping indexes: ary.each_with_object(Hash.new { |h, k| h[k] =3D [] }).with_index { |(el, h)= , idx| h[el.downcase] << idx } ``` With proposed method: ```ruby FONTS =3D { title: 'Arial', body: 'Times New Roman', blockquote: 'Tahoma' }.with_default('Courier').freeze ary.each_with_object({}.with_default { [] }).with_index { |(el, h), idx| h[= el.downcase] << idx } ``` About the block synopsys: I am not 100% sure, but I believe that _most_ of = the time when `default_proc` provided, it looks like `{ |h, k| h[k] =3D som= e_calculation }`. So, I believe for this "declarative simplification" of de= faults, it is acceptable to assume it as the only behavior (pass only key t= o block, and always store block's result); more flexible form would still b= e accessible with `Hash.new`. -- = https://bugs.ruby-lang.org/ Unsubscribe: