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 6731619C0048 for ; Thu, 19 Nov 2015 03:10:56 +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 A8CE0B5D834 for ; Thu, 19 Nov 2015 03:41:37 +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 A610718CC7EA for ; Thu, 19 Nov 2015 03:41:37 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 355CE120465; Thu, 19 Nov 2015 03:41:36 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o10.shared.sendgrid.net (o10.shared.sendgrid.net [173.193.132.135]) by neon.ruby-lang.org (Postfix) with ESMTPS id E8B98120459 for ; Thu, 19 Nov 2015 03:41:31 +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=lckuaSXWmL3Qlg4Yxj73q4VhRC0=; b=Ja7TrBg1BL1jVMrtLA jygEvogD9C87OjworE04jVJJf+bpy4f9jZYsfUn9owZ+cBhdDietA0Eo4yxIJF5J RrtBPkK6cfr2i4n0Dm2AT3rHW9IHVPc0ySxj8wW8egmUh6eyzAOnWFYL9OyauPUR 1M98h98hM/9bm9+OUyhso3oDQ= Received: by filter0603p1mdw1.sendgrid.net with SMTP id filter0603p1mdw1.16409.564CC64624 2015-11-18 18:41:10.337630137 +0000 UTC Received: from herokuapp.com (ec2-54-167-26-236.compute-1.amazonaws.com [54.167.26.236]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id lJ7NYNxaSe-gSJfX4vXocw for ; Wed, 18 Nov 2015 18:41:10.318 +0000 (UTC) Date: Wed, 18 Nov 2015 18:41:10 +0000 From: 6ftdan@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: 46226 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11690 X-Redmine-Issue-Author: danielpclark X-Redmine-Sender: danielpclark 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS6xOt3yiQWJ5krNtjBcMC5iI4EbbfJ/TUop8a 0U7MFdKB0FOTH5XovbifzukwWItBNOoif11WEEdUV49879svLBOnjFdTW5SdeBBNNVQbBKVPdZ0YNw zaMNvkWJZ1e6lNUITIpvvBszwKj/JZawYeEL X-ML-Name: ruby-core X-Mail-Count: 71562 Subject: [ruby-core:71562] [Ruby trunk - Feature #11690] Update Hash during multiple assignment 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 #11690 has been updated by Daniel P. Clark. I was thinking of what word(s) may best clarify this and not conflict with other potential uses. One issue about the word `assigned` is it seems like `self = ` or `replace`. I at first was thinking of `to_be` ... but that's sounds more like a promise of the future and each method would have to end in `ed` like so `x.to_be.updated = a: 1`. To avoid using a promise form and complex `ed` handling I was thinking of just `to`; `x.to.update`. But I don't think this is clear enough. So I have found the shortest thing I can think of that matches the statement `to_be_assigned_with`, and that is `apply`. It's short, simple, clear, and reveals to anyone that more is being done here. To copy from Nobuyoshi's idea ~~~Ruby class Applicable def initialize(obj) @target = obj end def method_missing(m, *args) @target.__send__(m.to_s.chomp('='), *args) end def respond_to_missing?(m) @target.respond_to?(m.to_s.chomp('=')) end end module Kernel def apply Applicable.new(self) end end x = {a: 1, b: 2} x.apply.update, y ,z = {c: 3}, 6, 7 p x ~~~ Arguably I think this is just as clear as `to_be_assigned_with`, and is different enough for people to notice that something else is going on here. That should be enough. ---------------------------------------- Feature #11690: Update Hash during multiple assignment https://bugs.ruby-lang.org/issues/11690#change-54944 * Author: Daniel P. Clark * Status: Open * Priority: Normal * Assignee: ---------------------------------------- Given that we can assign multiple variables at once ~~~ruby a,b,c = 1,2,3 ~~~ It would be nice to be able to update a Hash during multiple assignment rather than replacing it. Currently ~~~ruby x = {a: 1, b: 2} x, y ,z = {c: 3}, 6, 7 x # => {c: 3} ~~~ What I propose is adding `Hash#update=` to permit updating during multiple assignment. ~~~ruby class Hash def update=(h) update(h) end end x = {a: 1, b: 2} x.update, y ,z = {c: 3}, 6, 7 x # => {a: 1, b: 2, c: 3} ~~~ This would be most useful in scenarios where a method or proc return multiple values. When the method returns the values we don't normally know the key outside where the hash assignment is. ~~~ruby example = proc { [{:hi => :hello}, 5] } hash = {} # Currently in Ruby with an Unknown key multiple assignment isn't an option hash[????], current = example.call # We currently have to two step it result, current = example.call hash.update(result) ~~~ But with `Hash#update=` we don't have to know the key. -- https://bugs.ruby-lang.org/