[#8820] BEGIN as stmt. ? — EGUCHI Osamu <eguchi@...>
えぐち@エスアンドイーです。
5 messages
2000/01/04
[#8824] [REQ] Integer#{hex,dec,oct,bin}, String#bin — gotoken@... (GOTO Kentaro)
ごとけんです
38 messages
2000/01/05
[#8839] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— matz@... (Yukihiro Matsumoto)
2000/01/06
まつもと ゆきひろです
[#8842] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— gotoken@... (GOTO Kentaro)
2000/01/06
ごとけんです
[#8843] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— matz@... (Yukihiro Matsumoto)
2000/01/06
まつもと ゆきひろです
[#8844] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— gotoken@... (GOTO Kentaro)
2000/01/06
ごとけんです
[#8857] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— keiju@... (石塚圭樹)
2000/01/06
けいじゅ@日本ラショナルソフトウェアです.
[#8846] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— matz@... (Yukihiro Matsumoto)
2000/01/06
まつもと ゆきひろです
[#8847] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— gotoken@... (GOTO Kentaro)
2000/01/06
ごとけんです
[#8890] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— Koji Arai <JCA02266@...>
2000/01/08
新井です。
[#8914] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— matz@... (Yukihiro Matsumoto)
2000/01/12
まつもと ゆきひろです
[#8968] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— Koji Arai <JCA02266@...>
2000/01/19
新井です。
[#8976] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— WATANABE Hirofumi <Hirofumi.Watanabe@...>
2000/01/20
わたなべです.
[#9041] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— matz@... (Yukihiro Matsumoto)
2000/01/29
まつもと ゆきひろです
[#9045] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— gotoken@... (GOTO Kentaro)
2000/01/30
ごとけんです
[#9061] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— gotoken@... (GOTO Kentaro)
2000/02/02
ごとけんです
[#9077] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— matz@... (Yukihiro Matsumoto)
2000/02/04
まつもと ゆきひろです
[#9114] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— gotoken@... (GOTO Kentaro)
2000/02/04
ごとけんです
[#9116] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— matz@... (Yukihiro Matsumoto)
2000/02/05
まつもと ゆきひろです
[#9119] Re: [REQ] Integer#{hex,dec,oct,bin}, String#bin
— gotoken@... (GOTO Kentaro)
2000/02/05
ごとけんです
[#8828] Re: [ruby-list:20054] Re: == === case — Shugo Maeda <shugo@...>
前田です。
11 messages
2000/01/05
[#8829] Re: [ruby-list:20054] Re: == === case
— matz@... (Yukihiro Matsumoto)
2000/01/05
まつもと ゆきひろです
[#8866] DoubleFloat — gotoken@... (GOTO Kentaro)
ごとけんです
13 messages
2000/01/07
[#8867] Re: DoubleFloat
— EGUCHI Osamu <eguchi@...>
2000/01/07
えぐち@エスアンドイー です。
[#8869] Re: DoubleFloat
— gotoken@... (GOTO Kentaro)
2000/01/07
In message "[ruby-dev:8867] Re: DoubleFloat"
[#8886] Complex#divmod — Masahiro TANAKA <masa@...>
田中@ISASです。ついでに気になっていることを。
11 messages
2000/01/08
[#8895] Re: Complex#divmod
— keiju@... (石塚圭樹)
2000/01/10
けいじゅ@日本ラショナルソフトウェアです.
[#8899] Re: Complex#divmod
— matz@... (Yukihiro Matsumoto)
2000/01/10
まつもと ゆきひろです
[#8893] Re: [ruby-list:20142] Re: Range expansion? — Akinori MUSHA aka knu <knu@...>
knuです。ruby-listから舞台を移しました。
13 messages
2000/01/09
[#8906] Re: [ruby-list:20142] Re: Range expansion?
— Shugo Maeda <shugo@...>
2000/01/11
前田です。
[#8924] Re: [ruby-list:20142] Re: Range expansion?
— matz@... (Yukihiro Matsumoto)
2000/01/13
まつもと ゆきひろです
[#8925] Re: [ruby-list:20142] Re: Range expansion?
— Shugo Maeda <shugo@...>
2000/01/13
前田です。
[#8926] Re: [ruby-list:20142] Re: Range expansion?
— matz@... (Yukihiro Matsumoto)
2000/01/13
まつもと ゆきひろです
[#8941] [BUG] recycle the ruby_dyna_vars — Koji Arai <JCA02266@...>
新井です。
9 messages
2000/01/16
[#8953] rb_str2inum() — "Shigeo Kobayashi" <shigeo@...>
小林です。
5 messages
2000/01/18
[#8980] 1.4.3 patch for near-future *BSD IPv6 support — Jun-ichiro itojun Hagino <itojun@...>
近い将来の{Net,Free,Open}BSDにはKAME IPv6 stackが統合されています。
17 messages
2000/01/20
[#8981] Re: 1.4.3 patch for near-future *BSD IPv6 support
— Jun-ichiro itojun Hagino <itojun@...>
2000/01/20
> それから、
[#8989] Re: 1.4.3 patch for near-future *BSD IPv6 support
— MIYAJIMA Mitsuharu <miya@...>
2000/01/21
[#8996] Re: 1.4.3 patch for near-future *BSD IPv6 support
— Jun-ichiro itojun Hagino <itojun@...>
2000/01/21
[#9049] Re: 1.4.3 patch for near-future *BSD IPv6 support
— Katsuyuki Komatsu <komatsu@...>
2000/02/01
小松です。
[#8986] sort — gotoken@... (GOTO Kentaro)
ごとけんです
13 messages
2000/01/20
[#9004] DEFAULT_KCODE in rbconfig.rb — OKUNISHI -GTO- Fujikazu <fuji0924@...>
OS/2 隠居の奥西@京田辺市です。
8 messages
2000/01/22
[#9005] Re: DEFAULT_KCODE in rbconfig.rb
— matz@... (Yukihiro Matsumoto)
2000/01/23
まつもと ゆきひろです
[#9008] [PATCH] Array#flatten! for recursive array — nobu.nakada@...
なかだです。
9 messages
2000/01/24
[#9011] Re: [PATCH] Array#flatten! for recursive array
— matz@... (Yukihiro Matsumoto)
2000/01/24
まつもと ゆきひろです
[#9024] Re: [ruby-math:00115] Re: precedence of ** — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
4 messages
2000/01/26
[#9048] [PATCH] OS/2 patch improved for 1.5.0 — kenn@...
長沢です。
6 messages
2000/01/31
[ruby-dev:8923] Re: [REQ] Array#each{|a,b,...|}, Array#shift/pop(num)
From:
Kazunori NISHI <kazunori@...>
Date:
2000-01-12 21:05:53 UTC
List:
ruby-dev #8923
西@九大です。
From: Minero Aoki <aamine@dp.u-netsurf.ne.jp>
> つまり、splice は範囲のある削除の用途で使われることがほとんどであり、
> Ruby では範囲のある delete_at と slice! が採用されれば splice は
> 全く不要であると言ってよいでしょう。
...
> splice ARRAY add or remove elements anywhere in array
> ^^^^
> という記述を発見。これは Perl を使ってる人自身の意識を如実に
> 反映しているのでは?
どうも御苦労様でした。お蔭様で、納得する事ができました。という事で、
Array#splice は不要です。(コウモリ)。後は、他スレッドの
Array#extract
Array#delete_at
Array#slice/slice!
系の行方次第という事で。
> []= は相当使うのでそのたびに配列が生成されるのはさすがに厳しいものが
> あります。
あ、そうですね。実装に疎いと、実行時のコストを見落としがち、というか、
気付かない事が多いです。OO がいくら実行速度を優先しないと言っても、言
語設計(実装)レベルで、そういう無駄な処理は論外ですね。勉強になります。
> Ruby ではユーザが勝手に既存クラスにメソッドを追加できるので、
> 組みこみライブラリにいれるハードルは高くてもいいと思います。
前にも言いましたが、私はなるべく多くの機能が組み込みで提供される事を望
みます。もちろん「機能的に正しく、よい名前であれば」という条件節は設け
ますが。理由は、
[1] 各ライブラリ及びユーザ独自の定義における名前衝突の危険性
[2] 豊富な機能による利便性と豊富な語彙による可読性
です。[1]は、その可能性とそれが引き起こす誤動作が自明なので異論はない
でしょうが、[2]に関しては、殆ど精神論に近く、多少妄想が入ってるかもし
れないので、興味のない方は読み飛ばして下さい。(意訳:次のメールへ)
いくら「後から追加できる」「簡単に定義できる」と言っても、使う側として
は、自分が望む物がやはり最初から存在している(定義してある)方が便利です。
'a' と 'b' という2つのメソッドを連続して呼ぶ事が一度でもあれば、それを
'c' という組み込みメソッドとして用意しておいた方がいいと思っています。
確かに「簡単に後から定義できるんだから、自分で好きなようにやれ」と言わ
れそうですが(ていうか、言われてる)、Ruby と自然言語を対応づけて考える
と少しはわかってもらえるかもしれません。
私のイメージ的には(例えば「日本語」で考えると)、「平仮名さえ定義されて
いれば文章はかけるじゃん」と言われているような気分なのです。確かに平仮
名だけでも文章は書けますが、漢字があるとより便利。平仮名だけの文章に比
べると、焦点がボケ難く、より本質的な情報を伝え易い(可読性も高い)です。
平仮名(プリミティブなメソッド)の組み合わせで漢字(複合メソッド)相当もの
を表現する事も可能ですが、若者(入門者)が妙な当て字(妙なメソッド)を作り、
それらが流布する危険性や耐え難さ、そして言語自身への悪影響を考えると、
言語として最初から用意(定義)しておくべきではないのか。
その場合、生涯一度も使わないであろう単語も多く存在し、「豊富な語彙」と
いう名の下に、同じ意味を表す多くの異なる単語が存在してしまうが、そこに
は微妙なニュアンスがあり、それらがピタリとはまった時の文章(コード)の美
しさと爽快感は素晴しい、、、など、徒然と思っていますが、長くなるので、
このへんで。(最後がうまくまとまらなかったらしい)
要するに、言語自身が悪い言葉を持たない為の「ハードルの高さ」(機能的に
間違ってないか?名前は適切か?)はあって然るべきだと思いますが、それ以
上、少しでも敷居を高くする事には反対です。むしろ、上記の理由から、それ
を越えたものは積極的に取り込むべきであると。よって、「ユーザが勝手に既
存クラスにメソッドを追加できる」というのは言語の特徴にすぎず、その根拠
になるとは感じられないのです。
------------------------------------------------------------------
九州大学大学院システム情報科学研究科 情報工学専攻 博士後期課程三年
西 和則 ( e-mail: kazunori@swlab.csce.kyushu-u.ac.jp )
------------------------------------------------------------------