[#20127] protected_instance_methods(true) — Shin-ichiro HARA <sinara@...>
原です。
4 messages
2003/05/01
[#20163] Numeric#step — Koji Arai <JCA02266@...>
新井です。
13 messages
2003/05/05
[#20165] Re: Numeric#step
— Minero Aoki <aamine@...>
2003/05/05
青木です。
[#20167] Re: Numeric#step
— Koji Arai <JCA02266@...>
2003/05/05
新井です。
[#20169] Re: Numeric#step
— Minero Aoki <aamine@...>
2003/05/05
青木です。
[#20171] Re: Numeric#step
— Koji Arai <JCA02266@...>
2003/05/05
新井です。
[#20172] Re: Numeric#step
— Masahiro TANAKA <masa@...>
2003/05/06
At Tue, 6 May 2003 02:55:54 +0900,
[#20197] ARGF.filename — Koji Arai <JCA02266@...>
新井です。
6 messages
2003/05/17
[#20209] /()*\1/ =~ "" — Tanaka Akira <akr@...17n.org>
元ネタは BTS および Matzにっきなのですが、Matzにっきの調子が悪くてつっ
5 messages
2003/05/19
[#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>,
[#20245] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20248] Re: dyna_vars problem?
— Tanaka Akira <akr@...17n.org>
2003/05/20
In article <1053422521.786672.22712.nullmailer@picachu.netlab.jp>,
[#20250] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20251] Re: dyna_vars problem?
— Tanaka Akira <akr@...17n.org>
2003/05/20
In article <1053424909.383731.24667.nullmailer@picachu.netlab.jp>,
[#20255] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20268] splat restary — nobu.nakada@...
なかだです。
5 messages
2003/05/21
[#20303] [Oniguruma] possessive quantifier — kkosako@...
強欲な繰り返し演算子を実装してみたんですが、
1 message
2003/05/28
[#20307] [Oniguruma] intersection of char class — kkosako@...
Javaの正規表現で実現されている
4 messages
2003/05/30
[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)