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.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 6816C1F9FC for ; Sat, 27 Mar 2021 00:31:15 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E1183120AD0; Sat, 27 Mar 2021 09:30:09 +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 4BCC6120ACF for ; Sat, 27 Mar 2021 09:30:07 +0900 (JST) Received: by filterdrecv-p3iad2-7d7c446bd4-mfhjf with SMTP id filterdrecv-p3iad2-7d7c446bd4-mfhjf-21-605E7CC7-3A 2021-03-27 00:31:03.342776948 +0000 UTC m=+280678.248043630 Received: from herokuapp.com (unknown) by ismtpd0166p1iad2.sendgrid.net (SG) with ESMTP id WdxFi6EPQo6IY1nRElgFYg for ; Sat, 27 Mar 2021 00:31:03.287 +0000 (UTC) Date: Sat, 27 Mar 2021 00:31:03 +0000 (UTC) From: yoelblumenator@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79081 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17472 X-Redmine-Issue-Author: naruse X-Redmine-Sender: joelb 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?ck0Ozjtcb+RCIkYsi=2FCCpJToM5PKL46x0pfj3ASrbyd1jbIXHlW5IqDy8rF9Nc?= =?us-ascii?Q?Gz4EGWt=2FJxxopPC3=2FPsZ6FEmr7PP9arsTG9mG5l?= =?us-ascii?Q?NrLgfIFHf122nEsMOBK=2FDCK+IHxhnRHkhl4k4KT?= =?us-ascii?Q?mQmRPQp5BXG0VoOAaJi32nKXhPubuvOCSr9QAzA?= =?us-ascii?Q?jOv5Vltyy0Bwp9ai7ETPjSb8EszaGAHvD7ohgvh?= =?us-ascii?Q?iwlAwecNQXgA7CLcw=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103046 Subject: [ruby-core:103046] [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 joelb (Joel Blum). > I think the critical use case for HashWithIndifferentAccess is params; where you want to be using symbol keys because it's cleaner syntax, but the keys are coming from untrusted input We can agree the vast majority of Ruby devs are web programmers, mostly with Rails. So they also write a lot of javascript and obviously they prefer the js syntax {name: 'joe'} to rocket {'name' => 'joe'}, so they mostly use symbols **under the hood** (emphasized because the developer 99% of the time doesn't care whether it's a symbol or a string during normal, routine web/Rails work. The developer simply wants a dictionary with string like keys and prefers to use the js object notation). So if 99% of the time you don't care whether it's a symbol or a string, yet the popular hash syntax goes for symbol keys, what happens is every time you do JSON.parse you will get stringified keys and it's very easy to see why from a user point a view some indifferent construct makes sense. The truth is most of us ARE indifferent, we just want a dictionary with string like names. ---------------------------------------- Feature #17472: HashWithIndifferentAccess like Hash extension https://bugs.ruby-lang.org/issues/17472#change-91107 * 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/