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 6078F19E005C for ; Fri, 18 Dec 2015 12:36:37 +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 6D0AEB5D90A for ; Fri, 18 Dec 2015 13:08:44 +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 C872218CC7E6 for ; Fri, 18 Dec 2015 13:08:44 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 087651204E5; Fri, 18 Dec 2015 13:07:11 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by neon.ruby-lang.org (Postfix) with ESMTPS id 8BADF120520 for ; Fri, 18 Dec 2015 13:06:28 +0900 (JST) Received: by mail-io0-f174.google.com with SMTP id e126so77625579ioa.1 for ; Thu, 17 Dec 2015 20:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:subject:mime-version:content-type; bh=WBsgatb0YzAJ8XMwDlCxUvfoqEGfihOunlk1qeoJdbI=; b=GOgWizEoJAsFJMYwAHkihN7Uiwnc1p2K0/RNQ+6lijgI6vAzoyx9BqkxDJm2+kufsR 1c8oFGgRg2/UKqaE7Kz1wAswMFoj/7791MvKbUY2PcLxVYfwx9WUAP1gGZUYpelCjcdQ 3rRDvwqjczjgqvAAvmSU4E9X4s07VUEUO9MVZ/X5So49/hbBhQe9YWQZdxiTntjRMlfS 0+YlYaNexiGW/9OWg658OT1mySYnUiTLFXQShSwv+iMSaQKjQd3xX19PKx2hFfQ1e0yN VzC05GKGYacoQGXISIOW6UYVTntWFbL7k3yVWxgTK+lMTaGy5cnTtxAMQGthuw+RHRMq Yu8g== X-Received: by 10.107.11.68 with SMTP id v65mr2229015ioi.188.1450411586966; Thu, 17 Dec 2015 20:06:26 -0800 (PST) Received: from Josephe-Jones (75-166-130-47.hlrn.qwest.net. [75.166.130.47]) by smtp.gmail.com with ESMTPSA id b10sm1943415igx.19.2015.12.17.20.06.26 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Dec 2015 20:06:26 -0800 (PST) Date: Thu, 17 Dec 2015 21:06:25 -0700 From: Joseph Jones To: Ruby developers Cc: Message-ID: <71E32B49-E7CE-42FF-8409-EAF98B2028D0@gmail.com> X-Mailer: BoxerFree 6.0.4 (321) X-Boxer-Generated: true X-Boxer-IsLike: true MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="56738641_4516dde9_16c" X-ML-Name: ruby-core X-Mail-Count: 72269 Subject: [ruby-core:72269] [Ruby trunk - Feature #11747] \"bury\" feature, similar to 'dig' but opposite 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" --56738641_4516dde9_16c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joseph Jones liked your message with Boxer. On December 2, 2015 at 16:36:= 12 MST, dameyawn=40gmail.com wrote:Issue =2311747 has been updated by dam= ien sutevski.Tsuyoshi Sawada wrote:> > inferred from the what the user is= passing (such as a symbol or string for a hash or an integer for an arra= y)> > I don't think this is a good idea. I think it should rather depend = on the class of the receiver.> > =7B=7D.bury(:users, 0, :name, 'Matz') =23= =3D> =7B:users =3D> =7B0 =3D> =7B:name =3D> =22Matz=22=7D=7D=7D> =5B=5D.= bury(:users, 0, :name, 'Matz') =23 =3D> error> =7B=7D.bury(0, 1, 2, :foo)= =23 =3D> =7B0 =3D> =7B1 =3D> =7B2 =3D> :foo=7D=7D=7D> =5B=5D.bury(0, 1, = 2, :foo) =23 =3D> =5B=5Bnil, =5Bnil, nil, :foo=5D=5D=5D> > and similar fo= r struct.I agree. I should clarify that I was assuming the class of the r= eceiver (=60data=60) was known in my example. The inference I was talking= about was that a buried =600=60 would imply an array position by default= instead of a hash key.----------------------------------------=46eature = =2311747: =22bury=22 feature, similar to 'dig' but opposite https://bugs.= ruby-lang.org/issues/11747=23change-55211* Author: damien sutevski* Statu= s: =46eedback* Priority: Normal* Assignee: Yukihiro Matsumoto------------= ----------------------------In Matz's recent Rubyconf talk, he used this = example for the new 'dig' feature coming in Ruby 2.3:=7E=7E=7Eruby=23 we = want thisdata=5B:users=5D=5B0=5D=5B:name=5D=23 we can do this w/o nil err= orsdata.dig(:users, 0, :name)=7E=7E=7EWhat I'm proposing is a 'bury' feat= ure that is the opposite of 'dig' in a sense. It inserts a value at an ar= bitrary depth, for example:=7E=7E=7Erubydata.bury(:users, 0, :name, 'Matz= ')=7E=7E=7EThis will create a nested hash or an array automatically at ea= ch step if it doesn't already exist, and that can be inferred from the wh= at the user is passing (such as a symbol or string for a hash or an integ= er for an array). It's similar to autovivification but more powerful=21Th= is behavior is very common, at least in my experience, so a dry method bu= ilt into Ruby would be awesome=21 -- https://bugs.ruby-lang.org/ --56738641_4516dde9_16c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joseph Jones liked your message with Boxer.


= On December 2, 2015 at 16:36:12 MST, dameyawn=40gmail.com wrote:
Issue =2311747 has been update= d by damien sutevski.


Tsuyoshi Sawada wrote:
> > i= nferred from the what the user is passing (such as a symbol or string for= a hash or an integer for an array)
>
> I don't think this is = a good idea. I think it should rather depend on the class of the receiver= .
>
> =7B=7D.bury(:users, 0, :name, 'Matz') =23 =3D> =7B:u= sers =3D> =7B0 =3D> =7B:name =3D> =22Matz=22=7D=7D=7D
> =5B=5D.b= ury(:users, 0, :name, 'Matz') =23 =3D> error
> =7B=7D.bury(0, 1,= 2, :foo) =23 =3D> =7B0 =3D> =7B1 =3D> =7B2 =3D> :foo=7D=7D=7D
> = =5B=5D.bury(0, 1, 2, :foo) =23 =3D> =5B=5Bnil, =5Bnil, nil, :foo=5D=5D=5D=
>
> and similar for struct.

I agree. I should clar= ify that I was assuming the class of the receiver (=60data=60) was known = in my example. The inference I was talking about was that a buried =600=60= would imply an array position by default instead of a hash key.



----------------------------------------
=46ea= ture =2311747: =22bury=22 feature, similar to 'dig' but opposite
ht= tps://bugs.ruby-lang.org/issues/11747=23change-55211

* Author:= damien sutevski
* Status: =46eedback
* Priority: Normal
*= Assignee: Yukihiro Matsumoto
--------------------------------------= --
In Matz's recent Rubyconf talk, he used this example for the new = 'dig' feature coming in Ruby 2.3:

=7E=7E=7Eruby
=23 we wa= nt this
data=5B:users=5D=5B0=5D=5B:name=5D

=23 we can do = this w/o nil errors
data.dig(:users, 0, :name)
=7E=7E=7E
<= br />What I'm proposing is a 'bury' feature that is the opposite of 'dig'= in a sense. It inserts a value at an arbitrary depth, for example:
=
=7E=7E=7Eruby
data.bury(:users, 0, :name, 'Matz')
=7E=7E=7E=

This will create a nested hash or an array automatically at e= ach step if it doesn't already exist, and that can be inferred from the w= hat the user is passing (such as a symbol or string for a hash or an inte= ger for an array). It's similar to autovivification but more powerful=21<= br />
This behavior is very common, at least in my experience, so a = dry method built into Ruby would be awesome=21



--=
https://bugs.ruby-lang.org/
<= /html> --56738641_4516dde9_16c--