[#380] bug report#3 and request#5 — keiju@... (Keiju ISHITSUKA)
けいじゅ＠SHLジャパンです.
1 message
1996/08/06
[ruby-list:383] Re: bug report#3 and request#5
From:
Date:
1996-08-07 09:26:17 UTC
List:
ruby-list #383
けいじゅ＠SHLジャパンです.
In [ruby-list :00381 ] the message: "[ruby-list:381] Re: bug report#3
and request#5 ", on Aug/07 11:17(JST) matz@caelum.co.jp (Yukihiro
Matsumoto) writes:
>|1. 多重代入
>|*foo = 1, 2, 3
>一応(現在の文法にないと言う意味では)仕様です．
>
> foo = [1,2,3]
>
>ではどうでしょう? 他の機能と衝突しないようですし，あっても良
>いのかなあ．
># 次のバージョンでは試験的に追加してみましょう．
foo, *bar = 1, 2, 3
foo, bar, *baz = 1, 2, 3
があるので
*foo = 1, 2, 3
もありかなと思っただけです.
でも, 多重代入はなかなか微妙な仕様ですね(^^;;
foo = 1, 2, 3
*foo = 1, 2, 3
はNGで
foo, = 1, 2, 3
は, foo == 1
foo = [1, 2, 3]
は, foo == [1, 2, 3]
となるわけですね.
>|2. Array#append
>|array1.append(array2)
>恥ずかしいミスです．おかしいなあ．
全然テストしなかったでしょう(^^;;; 確実に暴走するよ!!
>|そうそう. += があるのだから, array.append()はもしかしたら必要ないとい
>|うことはありませんか?
>まあ，ほとんどの場合は同じ動きをするんですけど，
>
> $x += $y
>
>は$xと$yを結合した新しい配列を作って，それを$xに代入するとい
>う意味になります．一方，
>
> $x.append($y)
>
>は$xが指している配列そのものを書き換えて，$xに$yの要素を追加
>するので，同じ配列を共有している場合に動きが違います．あと，
>少しだけメモリ効率が良いです．
なるほど, 前者が lisp の append に近くて 後者が nconc に近いわけね.
>|3. print File.stat("/etc")
>|構造体に関してなのですが, 構造体をprintすると ``struct Stat''としか出
>|ません. メンバに関して名前と値ぐらいを簡単にでいいから出してもらえない
>|でしょうか?
>inspectというメソッドで内容を詳しい文字列表現が得られます．
> print File.stat("/etc").inspect
>としてみてください．
inspectの存在は知っています.
print の定義を見ると そのオブジェクトの文字列表現(to_s)を印刷するとなっ
ていますよね. 構造体の文字列としての表現は, メンバ名と値の組みではなか
ろうかと思ったわけです. つまり, Hash見たいな感じでの表現ですね. Hashと
違って, メンバの並びが常に一定ならば, 値だけを並べてもらっても構いませ
ん.
>|4. fail/rescue
>質問じゃないなあ．^^;;
そうです?
>rescueの中で特定のエラーをとらえたい場合
(中略)
>変数 $! には(本来)エラーを示す文字列が格納されているわけです
>から，その文字列を使って分岐します．上の例では例外を1種類だ
>け補足していますが，複数の例外を補足するためには case文が便
>利でしょう．
いわんとすることは分かるのですが... そのエラーにおいてどのようなメッセー
ジが出てくるのかマニュアルとかないですよね.
>rescue節の中で，failを引数無しで呼ぶと現在の例外をそのまま上
>に投げますので，ここで捕捉しない例外はそれを使って上に任せれ
>ば良いと思います．
>
>failの使い方としては例外を発生させる時には，原則として例外の
>種類を示す文字列を引数として渡し，上の例のように例外のチェイ
>ンを行いたい時だけ引数無しのfailを用いると良いでしょう．
>これでどうでしょう．これではまだ使いにくいということでしたら，
>相談に乗ります．
そうですね. 特に機能を拡張しろとはいわないのですが, 以下のようなリクエ
ストがあります.
1. エラーメッセージをパターン化してほしい.
例えば,
クラス名:メソッド名:エラー名*
などの用にです. 現在でもそのようになっているような気もします. ただ, ク
ラス名がないので, つけた方が良いのではと思います.
2. エラー名* について, 本当は文字列とのマッチングをとるのではなくて,
IDがついているとさらにベストです.
例えば,
クラス名:メソッド名:エラーID:エラー名
などです.
その他に, クラス全体で一意のエラーIDを割り振るというてもありますね. こ
の方が良いかも知れません.
3.
これはドキュメントに関するリクエストです.
各メソッド毎に発生する可能性のあるエラーの種類をドキュメント上リストアッ
プして下さい.
今のままでは, メッセージが分からないので, 実際にエラーを起こしてエラー
メッセージを調べなくてはならないのでめんどくさいです.
# 3.が提供されるのが一番嬉しいという説もある(^^;;
__
..........................................石塚 圭樹＠SHLジャパン(株)...
------------->アドレス変わりました!! e-mail: keiju@shljapan.co.jp <----