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 (smtp.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id CDDCC1B40D9E for ; Thu, 16 Feb 2017 09:53:52 +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 AAF92B5D94E for ; Thu, 16 Feb 2017 10:22:54 +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 E9CC118CC83D for ; Thu, 16 Feb 2017 10:22:54 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 436891206A4; Thu, 16 Feb 2017 10:22:53 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 34101120683 for ; Thu, 16 Feb 2017 10:22:50 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=Dj57c/XiItfExYf2luH+CisqpQY=; b=CDs/8prHBs/vw/Rax9 LYZDJyulTRX1FWhyNXv7ZfQDwu0HLbT8TheLErk6pf17EmDNbZJ5+blhZ7xPmIpU MUEPP0oog+iCoM/2FgCw5+F7/TjnzJSDZL3+j2q3dwGKgZ/R5c9dKOgXaFhPpWvz HEWnx9Pps97yRbFxOxhmcjd3k= Received: by filter0534p1mdw1.sendgrid.net with SMTP id filter0534p1mdw1-31616-58A4FEE6-3 2017-02-16 01:22:46.180212512 +0000 UTC Received: from herokuapp.com (ec2-184-73-48-204.compute-1.amazonaws.com [184.73.48.204]) by ismtpd0004p1iad1.sendgrid.net (SG) with ESMTP id 1I5t8Al9TciLqJS6xktGhw Thu, 16 Feb 2017 01:22:46.061 +0000 (UTC) Date: Thu, 16 Feb 2017 01:22:45 +0000 From: subtileos@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 54483 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 7792 X-Redmine-Issue-Author: rosenfeld X-Redmine-Issue-Assignee: matz X-Redmine-Sender: subtileos 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS6AGVXlhfGgEW0Zzv0zEu7vwojHs9EtYzW/fC A+bUyfWMFrtB1vJUu1tT8y7qJcWKo2PcKZmNAOO+QneEWLxE4BZB7lgT9ap2rbSDgtsf3P7SFJJ3Fw H7Zub9WXFtzSTxqm43NZc2c/sh2VLE7bpemNLM310rgxQiRyAvbCd/3qng== X-ML-Name: ruby-core X-Mail-Count: 79546 Subject: [ruby-core:79546] [Ruby trunk Feature#7792] Make symbols and strings the same thing 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 #7792 has been updated by Daniel Ferreira. Hi Bill > One example: > > Since symbols aren't garbage collected, my Ruby-based RPC system > is designed by default to convert symbols in incoming messages to > strings instead. (PacketBuf.preserve_symbols_on_extract = false) > > This has led to sending certain internal messages with names > consisting of symbols instead of strings. These messages cannot > be spoofed by an external source, as there's no way for a remote > sender to produce messages locally containing symbols. > > (If not for the garbage collection problem, I would have designed > the system to preserve externally generated symbols, and so would > have then required a different approach to distinguish internal > vs. external message names. So current design is arbitrary in > that sense, but nevertheless, the symbol/string distinction is > being put to use.) With symbols being garbage collected now is this functionality broken or are you still relying on symbols over strings for your solution? Thanks, Daniel ---------------------------------------- Feature #7792: Make symbols and strings the same thing https://bugs.ruby-lang.org/issues/7792#change-62986 * Author: Rodrigo Rosenfeld Rosas * Status: Rejected * Priority: Normal * Assignee: Yukihiro Matsumoto * Target version: Next Major ---------------------------------------- Recently I had to replace several of my symbols to plain strings in my project. Here is what happened: I generated some results with some class that would add items to an array like this: results << {id: 1, name: 'abc'} Then I would store such results in cache using Redis, encoded as a JSON string. But then when I restore the data from cache the hash will be {'id' => 1, 'name' => 'abc'}. This wasn't a problem until recently because I never used the results directly in the same request before and would always use the value stored on Redis and parsed by JSON. But recently I had to use the values directly in a view. But then I had a problem because I would have to use symbols in the results for the first time and strings the next times when the result was available on cache. I really don't want to care about memory management in Ruby if possible and symbols forces me to abandon the new sexy hash syntax many times. Now I have to write results << {'id' => 1, 'name' => 'abc} when I'd prefer to write results << {id: 1, name: 'abc} This is not the first time I had a bad user experience due to symbols being different from strings. And I'm not the only one or ActiveSupport Hash#with_indifferent_access wouldn't be so popular and Rails wouldn't use it all the time internally. It is really bad when you have to constantly check how you store your keys in your hashes. Am I using symbols or strings as keys? If you use the wrong type on plain hashes you can find a bad time debugging your code. Or you could just use Hash#with_indifferent_access everywhere, thus reducing performance (I guess) and it is pretty inconvenient anyway. Or if you're comparing the keys of your hash in some "each" closure you have to worry about it being a symbol or a string too. Ruby is told to be programmers' friendly and it usually is. But symbols are certainly a big exception. -- https://bugs.ruby-lang.org/