[#20227] dyna_vars problem? — Tanaka Akira <akr@...17n.org>

しばらく前から、稀に Ruby が core を吐くという問題を追いかけているので

15 messages 2003/05/19
[#20234] Re: dyna_vars problem? — matz@... (Yukihiro Matsumoto) 2003/05/19

まつもと ゆきひろです

[#20236] Re: dyna_vars problem? — Tanaka Akira <akr@...17n.org> 2003/05/19

In article <1053363181.529491.30320.nullmailer@picachu.netlab.jp>,

[ruby-dev:20143] Re: Array#map

From: Koji Arai <JCA02266@...>
Date: 2003-05-02 16:56:42 UTC
List: ruby-dev #20143
新井です。

In message "[ruby-dev:20135] Re: Array#map"
  on 02 May 2003 04:01:43 +0900,
  matz@ruby-lang.org (Yukihiro Matsumoto) wrote:
> まつもと ゆきひろです

> |>  * 1.6の面倒をみるのが面倒になった
> |
> |1.6.9 出して打ちどめで全然問題ないと思います。バグももう直さ
> |ない。1.6 利用者はその方がうれしいと思います。ただ、.9 で最
> |後になるので、慎重に(^^
> 
> この慎重ってのに弱いんですよねえ。

preview を5回くらいこまめに出す覚悟でやればどうでしょう?
週1回くらいのペースでそれぞれの preview に期限を儲けて

たぶん、このようにガチガチにやるのが好みではないのだろうと推
察しますが。

> これは悩んでます。なんらかの方法で(1.8で)yield相当を提供した
> いんですが、とはいえProc#yieldとProcとBlockの両方を導入する
> のとですぐに結論は出せないし。

"1.8 で Proc#yield"、にこだわる理由が Proc#yield の利用者で
ない私にはわからないわけですが、

* 引数チェックのない proc 実行

* orphan な proc に対する break や retry で例外を発生させる 
  proc 実行

の両方とも 1.8 に望まれているということでよろしいでしょうか?
(後者は dRuby 用で前者は?)

[ruby-dev:19799]
> いも付与されるようになりました。でも、今改めて考えると一つの
> メソッドに複数の目的を付与するのはやっぱり良くないようにも思
> います。もし、可能であればlocal jumpについては上記のABBまた
> はABAでcallと揃えた方が良いと思います。

という考えの結論が現状のものなんでしょうか?
(Proc#yield の現状の動作はあまり検証してません。すいません)

> |* $stdin,$stdout,$stderr への代入の挙動
> |    ... 1.6 でも文句が出ないし、1.6 の仕様に戻すのが好み(ど
> |        うせ使われてないと思うし)
> 
> そーなんですよねえ。今のでは中途半端だし、とりあえず1.6に戻
> しても構わないかなあ。

構わないです(勝手^^;)。

> |* "".reverse! は "" を返すが、[].reverse! は nil を返す。
> |    ... どちらかへの統一が望まれるのではないかと(掘り返すな?^^;)。
> 
> あれ、Array#reverse! は self を返すべきですよね。これは直し
> ます。指摘してくださって感謝します。

bang method は、レシーバの状態が変わらなければ nil を返すが、
reverse! はその検出が難しいってことで上記をどっちにすべきか
悩んでらっしゃったと思います。が、「self を返すべき」という
結論が出ているのならそうしましょう。(私もどちらかと言えば 
self を返した方が良いと思います)

> |Tue Dec 11 03:40:23 2001  Yukihiro Matsumoto  <matz@ruby-lang.org>
> |
> |	* array.c (rb_ary_select): Array#select(n,m,...) now works like
> |	  Array#indexes(n,m,..). [new, experimental]
> 
> いろいろもめてるわりには結論が出ない件ですね。selectに複数の
> 役割を持たすのは良くないという意見も理解できますが、他によい
> 名前がないというのも事実です。今まで出たselect以外の名前では
> values_atが良いと思います。

じゃあ、もう一発考えてみます。

slice([1,2,3])

とかダメ押ししてみる。って ary[[1,2,3]] の案と同じか。
Hash#slice(start, len) なんてできないため、Hash#slice の機能
が Array#slice よりも少ないと言う点でもダメ。String#slice な
んて余計なものまで付いて来るし。単語としては良いと思ったので
すが。

後は、

Enumerable#select([indexes...])
Enumerable#select([indexes...]) { ... }

にする。うーん、こうしても、Hash の select と Enum の select 
が異なる挙動なのは悩ましいですね。どうしても Hash と Array 
の両方を満たすものが思い付かない。

ところで、現状の select は、[ruby-dev:15418] なんて意見が出
る点でこれまでのものと同程度によろしくないと思います

さらに、[ruby-dev:16124] での実装者にやさしくない点、でもう1
ポイントよろしくなさが抜きん出ます。

values_at でいいんじゃないかなあ。投げやりでなく。(投票して
みたいですね)

> ということは、残る懸案は
> 
>  * Proc#yield
>  * top_include
>  * select(index,...)
>  * $stdinなど
> 
> くらいですかね。

p /\n$/ =~ "\n"

も一応。

--
新井康司 (Koji Arai)

In This Thread