[#47766] Hashイテレーション中の新規キー追加 — masa <masap.hat@...>
畠山です。
10 messages
2011/01/20
[#47768] Re: Hashイテレーション中の新規キー追加
— Satoshi GUNJI <gunjisatoshi@...>
2011/01/21
郡司と申します。
[#47769] Re: Hashイテレーション中の新規キー追加
— masa <masap.hat@...>
2011/01/21
GyRCSCs7MyRHJDkhIxsoQgoKGyRCJF4kRCRiJEgkNSRzISI3NDtKJDUkcyEiJCpKVjt2JCIkaiQs
[#47780] Ruby1.9.2 と RDEについて — eiichi_maekawa@...
9 messages
2011/01/26
[#47781] Re: Ruby1.9.2 と RDEについて
— Koutarou Tanaka <from.kyushu.island@...>
2011/01/26
=1B$BEDCf$H?=3D$7$^$9!#=1B(B
[#47789] [ANN] ytl 0.0.2 リリース — "Miura Hideki" <m-72@...6.so-net.ne.jp>
三浦と申します
1 message
2011/01/28
[#47790] [].join.encoding # => #<Encoding:ASCII-8BIT> — "5.5" <5.5@...>
5.5 です。
11 messages
2011/01/29
[#47792] Re: [].join.encoding # => #<Encoding:ASCII-8BIT>
— "NARUSE, Yui" <naruse@...>
2011/01/29
成瀬です。
[#47798] Re: [].join.encoding # => #<Encoding:ASCII-8BIT>
— "5.5" <5.5@...>
2011/01/31
5.5 です。
[#47799] Re: [].join.encoding # => #<Encoding:ASCII-8BIT>
— "Shota Fukumori (sora_h)" <sorah@...>
2011/01/31
sora_hです。
[#47800] Re: [].join.encoding # => #<Encoding:ASCII-8BIT>
— "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
2011/01/31
きしもとです
[#47801] Re: [].join.encoding # => #<Encoding:ASCII-8BIT>
— "NARUSE, Yui" <naruse@...>
2011/01/31
成瀬です。
[#47794] [ANN] Ruby-GNOME2 0.90.6 — Kouhei Sutou <kou@...>
須藤です。
7 messages
2011/01/30
[ruby-list:47772] Re: Hashイテレーション中の新規キー追加
From:
masa <masap.hat@...>
Date:
2011-01-21 10:05:01 UTC
List:
ruby-list #47772
畠山です。
自己レス変です。やっと変更のプロセスを理解しました。
(このような意見は ruby-core に投げるべきかもしれませんが、(英語が苦手な) 日本の Ruby list (利用者)が知る機会
(or Google に拾われる場所) があっても良いのではと思い、こちらに継続して投稿させてもらいます)
参考
http://redmine.ruby-lang.org/issues/show/1535
おそらく、まつもとさんの
| hash = { 1=>2, 3=>4, 5=>6 }
| hash.each {|k, v| hash[k] = func(v) } #=> OK
| hash.each {|k, v| hash[k.to_s] = v } #=> always exception
|
|This does not cause compatibility problem because this just
|raises exception that has already been occurred indeterminately.
|I'll commit the following patch to trunk unless anyone says an
|objection.
I think it's a good idea. Go ahead.
という意思決定に決定的だったのが Endoh さんの
But I agree with Run Paint Run Run's opinion. It may lead to
difficult bug to indeterminately fail to add a new key.
この意見だと思うのですが、この indeterminately (不確定性) は順序が保存される場合と保存されない場合で意味が変わってきます。
順序が保存されない場合はいかなる場合も予測不能で不確定ですが、順序が保存される場合は限定的には予測可能で確定的です。
Run Paint Run Run さんが言っているように
The ideal resolution is that this code works correctly, regardless of
the dimensions of the data structures.
将来的にはこの禁止が解除されることを願っています。
畠山