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-Status: No, score=-2.5 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=no 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 CC1651F4B4 for ; Tue, 29 Dec 2020 20:34:42 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 9BA07120A29; Wed, 30 Dec 2020 05:33:50 +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 D5BB3120A1F for ; Wed, 30 Dec 2020 05:33:47 +0900 (JST) Received: by filterdrecv-p3iad2-74bd9fb996-6xc4h with SMTP id filterdrecv-p3iad2-74bd9fb996-6xc4h-18-5FEB92D6-26 2020-12-29 20:34:30.69215114 +0000 UTC m=+1632736.606303934 Received: from herokuapp.com (unknown) by ismtpd0109p1mdw1.sendgrid.net (SG) with ESMTP id 5oRqDAfdTyucvtESyT3b0w for ; Tue, 29 Dec 2020 20:34:30.527 +0000 (UTC) Date: Tue, 29 Dec 2020 20:34:30 +0000 (UTC) From: zverok.offline@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 77709 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17472 X-Redmine-Issue-Author: naruse X-Redmine-Sender: zverok 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?3be0g8093pjUjT94eiCA64csFDBI=2FmHQTWm54P5gda4aQlk=2FSwveLVRuewPGdR?= =?us-ascii?Q?yNYftl1M4sJIaDVb9A840lFV43Q1z=2FZ363TC=2F7T?= =?us-ascii?Q?9UKzjer6RMj5aPKtpPD1zVjp8qCq4y+2LGX0q7u?= =?us-ascii?Q?rcH8YUMAsXtyF1+kf9Mta4sDDrZcarBG0P8b+70?= =?us-ascii?Q?WI2AfgMPizypRLTWSooGazQt9sTOAe5ESm0smJZ?= =?us-ascii?Q?M9=2F8dmU+yL99nDH6o=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 101807 Subject: [ruby-core:101807] [Ruby master Feature#17472] HashWithIndifferentAccess like Hash extension 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="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #17472 has been updated by zverok (Victor Shepelev). I believe that `HashWithIndifferentAccess` is one of the very false ideas in Rails -- and that as of today, it is a more or less common understanding in the community. The distinction of Symbol (as a controlled internal name) and String (as an input/output user data) is one of the very powerful concepts in Ruby, and the "I don't want to think whether it is Symbol or String, internal or external" is explicitly against this distinction (as far as I can understand, the holders of this ideas would actually prefer to have ONLY strings, but have a shorter syntax for string keys, like in JS, and that's how they perceive symbols). Eventually, even Rails started to make a clearer distinction between internal/external (see StrongParams), but HWIA is so omnipresent there, that they doubtfully get rid of it anytime soon. But I don't believe it is a reason to introduce it in a core language (not even mentioning the fact that the reason "Rails uses it, and it should be implemented in C, let's add it to the language core" feels quite weird). I am really surprised that Ruby core developers feel so positive about it. ---------------------------------------- Feature #17472: HashWithIndifferentAccess like Hash extension https://bugs.ruby-lang.org/issues/17472#change-89634 * Author: naruse (Yui NARUSE) * Status: Open * Priority: Normal * Target version: 3.1 ---------------------------------------- Rails has [ActiveSupport::HashWithIndifferentAccess](https://api.rubyonrails.org/classes/ActiveSupport/HashWithIndifferentAccess.html), which is widely used in Rails to handle Request, Session, ActionView's form construction, ActiveRecord's DB communication, and so on. It receives String or Symbol and normalize them to fetch the value. But it is implemented with Ruby. If we provide C implementation of that, Rails will gain the performance improvement. summary of previous discussion: https://github.com/rails/rails/pull/40182#issuecomment-687607812 -- https://bugs.ruby-lang.org/