[#72745] [Ruby trunk - Misc #11876] [Closed] Scheduled maintenance 2016/01/01 — shibata.hiroshi@...
Issue #11876 has been updated by Hiroshi SHIBATA.
4 messages
2016/01/07
[#72746] Re: [Ruby trunk - Misc #11876] [Closed] Scheduled maintenance 2016/01/01
— Eric Wong <normalperson@...>
2016/01/07
shibata.hiroshi@gmail.com wrote:
[#72824] [Ruby trunk - Bug #11973] IO#advise should raise NotImplementedError on platforms that do not support that call — git@...
Issue #11973 has been updated by Chuck Remes.
3 messages
2016/01/12
[#72954] [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each — naruse@...
Issue #12010 has been reported by Yui NARUSE.
4 messages
2016/01/20
[#72959] Re: [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each
— Eric Wong <normalperson@...>
2016/01/20
naruse@airemix.jp wrote:
[#73313] [Ruby trunk - Bug #12007] [Open] Newly added Unicode data file doesn't get downloaded — shugo@...
Issue #12007 has been updated by Shugo Maeda.
3 messages
2016/01/23
[#73372] [Ruby trunk - Misc #12004] Code of Conduct — benton@...
Issue #12004 has been updated by Benton Barnett.
4 messages
2016/01/24
[#73379] Re: [Ruby trunk - Misc #12004] Code of Conduct
— KOSAKI Motohiro <kosaki.motohiro@...>
2016/01/24
On Sun, Jan 24, 2016 at 5:13 PM, <benton@bentonbarnett.com> wrote:
[#73421] [Ruby trunk - Misc #12004] Code of Conduct — nekocat432@...
Issue #12004 has been updated by Ruby Dino.
6 messages
2016/01/25
[#73425] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Austin Ziegler <halostatue@...>
2016/01/25
I’m sorry, but this, like the code of merit, is merely a derailing tactic.
[#73469] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Martin J. Dürst <duerst@...>
2016/01/26
On 2016/01/26 01:32, Austin Ziegler wrote:
[#73482] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Austin Ziegler <halostatue@...>
2016/01/26
On Tue, Jan 26, 2016 at 12:25 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp>
[#73491] [Ruby trunk - Misc #12004] Code of Conduct — git@...
Issue #12004 has been updated by Chuck Remes.
7 messages
2016/01/26
[#73492] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Andrew Kirilenko <andrew.kirilenko@...>
2016/01/26
They will never provide any numbers because they are not engineers and they
[#73494] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Brandon Weaver <keystonelemur@...>
2016/01/26
Coraline is a panelist on Ruby rogues and a very well respected member of
[#73498] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Andrew Kirilenko <andrew.kirilenko@...>
2016/01/26
OK, sorry for previous comment. Let's try this way.
[#73500] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Austin Ziegler <halostatue@...>
2016/01/26
On Tue, Jan 26, 2016 at 5:15 PM, Andrew Kirilenko <
[#73558] [Ruby trunk - Misc #12004] Code of Conduct — andrew.kirilenko@...
Issue #12004 has been updated by Andrew Kirilenko.
5 messages
2016/01/28
[#73568] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Austin Ziegler <halostatue@...>
2016/01/29
Andrew, please stop digging. Your hole is only getting deeper.
[#73573] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Andrew Kirilenko <andrew.kirilenko@...>
2016/01/29
>Andrew, please stop digging. Your hole is only getting deeper.
[#73586] [Ruby trunk - Misc #12004] Code of Conduct — andrew@...
Issue #12004 has been updated by Andrew Vit.
4 messages
2016/01/29
[#73593] [Ruby trunk - Bug #12034] RegExp does not respect file encoding directive — nobu@...
Issue #12034 has been updated by Nobuyoshi Nakada.
3 messages
2016/01/30
[ruby-core:73596] [Ruby trunk - Feature #11882] Map or NamedMap
From:
andrew@...
Date:
2016-01-30 04:08:32 UTC
List:
ruby-core #73596
Issue #11882 has been updated by Andrew Vit.
Robert A. Heiler wrote:
> I concur with Hampton Catlin for the most part (save for the
> name "Map", that is not a good name IMO).
"Dict" is another possible name.
How would this proposal handle other key types? Should `obj[1] = 'a'` convert using `to_s` or raise an error?
----------------------------------------
Feature #11882: Map or NamedMap
https://bugs.ruby-lang.org/issues/11882#change-56791
* Author: Hampton Catlin
* Status: Open
* Priority: Normal
* Assignee: Yukihiro Matsumoto
----------------------------------------
Hash is one of the best features of Ruby. I remember being so pleased when I first learned Ruby to find out that *anything* could be a key and that you could do some really clever things with scripts, if you key of non-traditional elements.
However, like many people, 10 years into using Ruby, I still am writing code to cast around symbols to strings and strings to symbols, just to use Hash as a more traditional dictionary, keyed with string-like values. And, explaining to a junior programmers why they broke the code by using a key of a different type... it's not the most elegant thing to have to explain over and over.
Several proposals exist for how to deal with this, and all have been rejected... however it doesn't seem like it's for essential reasons, more technical or syntactic issues. Coming up with syntax is something I quite enjoy (Sass/Haml), so I thought I'd make a pitch for it.
Requirements:
1) Doesn't break existing code
2) Doesn't totally destroy the parser
3) Seems simple to differentiate
4) Clear upgrade path
My proposal is to introduce an entirely different type of Hash, called a Map (or NamedMap, if that's too ambiguous), that requires a string-like key. There are no other types of keys allowed on this Hash, other than either strings or symbols. Internally, each key would be considered a symbol only.
~~~
map = Map.new(a: 2, b: 3)
map["a"] #=> 2
map[:a] #=> 2
~~~
Already, we're better than HashWithIndifferentAccess, as it's clearly a bit easier to type. ;)
What about a literal syntax?
~~~
map = {{a: 2}}
empty_map = {{}}
~~~
As far as I can tell in the Ruby-syntax style, this should be pretty easy to distinguish syntactically from both a regular hash literal and a block. Further, as almost every method's option hash is string-keyed, you could easily define this.
~~~
def my _method(arg1, options = {{}})
end
~~~
Immediately, you could deal with your options hash, and not have to stress about if the end user has passed in strings or symbols into the options.
It would be trivial to create a Map polyfill for most libraries to start using the non-literal version right away, as it would basically be HashWithIndifferentAccess, except we need to guarantee that the keys are string-like.
So, to sum up, we avoid the 'breaking other people's existing code' by introducing a new data-type, the literal syntax (I think) should be fairly easy to implement, and it makes a very natural keyed data object (e.g. Javascript Objects) and brings that to Ruby.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>