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 8B87519E005C for ; Fri, 18 Dec 2015 21:27:02 +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 E34C9B5D86F for ; Fri, 18 Dec 2015 21:59:09 +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 9C67818CC7B2 for ; Fri, 18 Dec 2015 21:59:10 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 5918B1204F2; Fri, 18 Dec 2015 21:59:09 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by neon.ruby-lang.org (Postfix) with ESMTPS id 29531120410 for ; Fri, 18 Dec 2015 21:59:04 +0900 (JST) Received: by mail-io0-f172.google.com with SMTP id o67so88385966iof.3 for ; Fri, 18 Dec 2015 04:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:in-reply-to:message-id:date:to :content-transfer-encoding:mime-version; bh=wTWq9XmBsAtkqHu2kLcytSlYIm4asEDA6uMnEX3/gQQ=; b=bS4Z28J5K1s4pzTxDbp9laG9DM081eWnFiPJX/c9iDy4xSy4IZAVQB37dGziR8Ygr6 60UavsqNsKPbhYkqmQvl9H04DZuo1rPvCrKsFRWJTAUMKUNp+wyJ6hJcs7eHPx80njiD oexLu2Qr66N2GOEYP7/d6jBspw42OM7SgNCG4BYgI6bYmjZ4kc3TL8tRQsPHGB6aZoIn MEgOZp47dZQWK3MTe9rbAAkvNw0MabpKlPBWJlmlkoRaL7vGZQxt0LnquzxWXSN7kLe0 wkA7ZBOtoT1pqpvi+n2bTmxuWEXYZQWruKFmjI9FTiUmJGkdCDLMBoQR0tkSdBdwlbqm Lgkg== X-Received: by 10.107.16.213 with SMTP id 82mr5256602ioq.119.1450443542356; Fri, 18 Dec 2015 04:59:02 -0800 (PST) Received: from [192.168.1.72] (162-231-121-14.lightspeed.tukrga.sbcglobal.net. [162.231.121.14]) by smtp.gmail.com with ESMTPSA id 7sm2956131igr.0.2015.12.18.04.59.01 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 04:59:01 -0800 (PST) References: <71E32B49-E7CE-42FF-8409-EAF98B2028D0@gmail.com> From: Billy E Brand Content-Type: multipart/alternative; boundary=Apple-Mail-A0F510F5-5696-4BEC-B513-A977A91CA918 X-Mailer: iPhone Mail (13C75) In-Reply-To: <71E32B49-E7CE-42FF-8409-EAF98B2028D0@gmail.com> Message-Id: Date: Fri, 18 Dec 2015 07:58:19 -0500 To: Ruby developers Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-ML-Name: ruby-core X-Mail-Count: 72366 Subject: [ruby-core:72366] Re: [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" --Apple-Mail-A0F510F5-5696-4BEC-B513-A977A91CA918 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Remove me from mail list please=20 Sent from my iPhone Billy E Brand 404-597-9615 > On Dec 17, 2015, at 23:06, Joseph Jones wrote: >=20 > Joseph Jones liked your message with Boxer. >=20 >=20 >> On December 2, 2015 at 16:36:12 MST, dameyawn@gmail.com wrote: >> Issue #11747 has been updated by damien sutevski. >>=20 >>=20 >> Tsuyoshi Sawada wrote: >> > > inferred from the what the user is passing (such as a symbol or strin= g for a hash or an integer for an array) >> >=20 >> > I don't think this is a good idea. I think it should rather depend on t= he class of the receiver. >> >=20 >> > {}.bury(:users, 0, :name, 'Matz') # =3D> {:users =3D> {0 =3D> {:name =3D= > "Matz"}}} >> > [].bury(:users, 0, :name, 'Matz') # =3D> error >> > {}.bury(0, 1, 2, :foo) # =3D> {0 =3D> {1 =3D> {2 =3D> :foo}}} >> > [].bury(0, 1, 2, :foo) # =3D> [[nil, [nil, nil, :foo]]] >> >=20 >> > and similar for struct. >>=20 >> I agree. I should clarify that I was assuming the class of the receiver (= `data`) was known in my example. The inference I was talking about was that a= buried `0` would imply an array position by default instead of a hash key. >>=20 >>=20 >>=20 >>=20 >> ---------------------------------------- >> Feature #11747: "bury" feature, similar to 'dig' but opposite=20 >> https://bugs.ruby-lang.org/issues/11747#change-55211 >>=20 >> * Author: damien sutevski >> * Status: Feedback >> * Priority: Normal >> * Assignee: Yukihiro Matsumoto >> ---------------------------------------- >> In Matz's recent Rubyconf talk, he used this example for the new 'dig' fe= ature coming in Ruby 2.3: >>=20 >> ~~~ruby >> # we want this >> data[:users][0][:name] >>=20 >> # we can do this w/o nil errors >> data.dig(:users, 0, :name) >> ~~~ >>=20 >> 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: >>=20 >> ~~~ruby >> data.bury(:users, 0, :name, 'Matz') >> ~~~ >>=20 >> This will create a nested hash or an array automatically at each step if i= t doesn't already exist, and that can be inferred from the what the user is p= assing (such as a symbol or string for a hash or an integer for an array). I= t's similar to autovivification but more powerful! >>=20 >> This behavior is very common, at least in my experience, so a dry method b= uilt into Ruby would be awesome!=20 >>=20 >>=20 >>=20 >> --=20 >> https://bugs.ruby-lang.org/ --Apple-Mail-A0F510F5-5696-4BEC-B513-A977A91CA918 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Remove me from mail list please <= br>
Sent from my iPhone
Billy E Brand
404-597-9615

On Dec 17, 2015, at 23:06, Joseph Jones <joeyi5216@gmail.com> wrote:

Joseph Jones liked your message with Boxer.


On Dec= ember 2, 2015 at 16:36:12 MST, dameyaw= n@gmail.com wrote:
Issue #11747 h= as been updated by damien sutevski.


Tsuyoshi Sawada wrote:
>= ; > inferred from the what the user is passing (such as a symbol or stri= ng for a hash or an integer for an array)
>
> I don't think thi= s is a good idea. I think it should rather depend on the class of the receiv= er.
>
> {}.bury(:users, 0, :name, 'Matz') # =3D> {:users= =3D> {0 =3D> {:name =3D> "Matz"}}}
> [].bury(:users, 0, := name, 'Matz') # =3D> error
> {}.bury(0, 1, 2, :foo) # =3D> {= 0 =3D> {1 =3D> {2 =3D> :foo}}}
> [].bury(0, 1, 2, :foo) #= =3D> [[nil, [nil, nil, :foo]]]
>
> and similar for struct.<= br>
I agree. I should clarify that I was assuming the class of the receiv= er (`data`) was known in my example. The inference I was talking about was t= hat a buried `0` would imply an array position by default instead of a hash= key.




----------------------------------------
Feature= #11747: "bury" feature, similar to 'dig' but opposite
https://bugs.ruby-lang.org/i= ssues/11747#change-55211

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

~~~ruby
#= we want this
data[:users][0][:name]

# we can do this w/o nil erro= rs
data.dig(:users, 0, :name)
~~~

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:

~~~ruby
data.bury(:users, 0, :name,= 'Matz')
~~~

This will create a nested hash or an array automatica= lly at each step if it doesn't already exist, and that can be inferred from t= he what the user is passing (such as a symbol or string for a hash or an int= eger for an array). It's similar to autovivification but more powerful!
<= br>This behavior is very common, at least in my experience, so a dry method b= uilt into Ruby would be awesome!



--
https://bugs.ruby-lang.org/
= --Apple-Mail-A0F510F5-5696-4BEC-B513-A977A91CA918--