読書会(Scalaスケーラブルプログラミング)第4回議事録

Scalaスケーラブルプログラミング第4回議事録
2010年2月27日

参加者: 遠藤、岩室、石黒、高橋(徹)、松永、村山、久保田、高橋(智)、中島、
        高原、小棚木、門脇

書記: 岩室

p.212-

■12.5 積み重ね可能な変更をそれぞれのトレイトで表現する

・「フィルタリング」について、p212の説明では「取り除く」となっているが、
  実装では、条件に合わないものを追加せず無視している。
・p215のnewをカッコでくくる意味は?
  → 複数行にまたがっているので、継続の意味ではないか?
・JavaのStream系のAPIに似ている。
・Javaのinterfaceだと、宣言されたメソッドを全部実装する必要があるが、
  こちらは特定のメソッドだけを実装できる。
・必要なところだけフィルタを書けるのは便利。
・でもwith, with, ...と続くのはつらい?
・Javaよりは楽だけど、やっぱり実装が大変?
・aspectチックに書けるのがうれしい。
・Javaのaspectは準備が大変。
  → 最近のaspectではjavaagentが使える(動的に設定できる)
・aspectとしての機能が言語として組み込まれているのは良い。Javaのaspect
  は後付け。
・特定のインスタンスにだけ付けるのは良い。(検証とか)
・Javaの無名クラスと似ているが、traitは事前に定義されている点がちがう。
・部品をいろいろ用意して、いろいろ組み合わせることができる。
  →Javaの無名クラスとは異なる。
・「without」のようなものは無いのか?(笑)

■12.6 Scalaが多重継承ではなくミックスイン合成を選んだ理由

・p217 L3 → 誤訳?
  「インクリメントし、かつ倍にする、という処理がおこなわれない」ではないか?
・同じtraitを複数withで指定できるか?→宿題
・p218の図がよくわからない。
・traitの継承はやらない方がよい?
・トレイトの継承は、熟練しないと使ってはいけないのでは。

■12.7 トレイトすべきか、せざるべきか

・・「Javaコード【を】継承できるようにしたい場合」
  ○「Javaコード【で】継承できるようにしたい場合」
  ではないか?
・Javaのinterfaceのメソッド呼び出しは遅い。
  → が、それが本当にボトルネックになるか?
     ロジックを変えた方が速くなることは多い。

■12.8 まとめ

・深い。
・間違った継承ツリーを後から変えるのは大変だが、traitの方はやりやすい。
・ゴミみたいなtraitが量産されないか?
・細かいものを組み上げていくのがlisp的に感じる。
・一人プロジェクトなら良いが、複数人だと使えるか?
・traitのoverrideしてないメソッドは呼べるか? → 呼べる。
・多重継承の解決
  ⇒実装の継承?
    trait/mix-in
    C++テンプレート
・「遺伝継承」?
・トレイト? 特性?

13章パッケージとインポート

■13.1 パッケージ

・リスト13.5: 何故Booster2がこの構文になる?
  → Booster2はnavigationの中にない。
・「_root_」が微妙。
・"."から始めればいいのではないか? (C++だと、::から始める)
  → "."はいろいろなところで使われるから無理ではないか?

■13.2 インポート

・catch-all節って何?

■13.3 暗黙のインポート

■13.4 アクセス修飾子

・private[this]って何?
  → 同一クラス内でも、オブジェクトが違えばアクセスできない

・13.4.4「Xまでは非公開あるいは限定公開だという意味になる」
  →意味が取りづらい。

・[]内は階層構造以外に指定できるか?

・[]内に複数指定できるか?→できなさそう?

・Javaから見たらどう見える?

■13.5 まとめ

14章表明と単体テスト

■14.1 表明(assertions:アサーション)

・ensuring はどう振る舞う?

・Javaのassertの挙動を変えられないのは不便。組み込みだと「assertでfail
  したときにデバッガを起動する」といったことをしたいのだが、できない。

■14.2 Scalaにおける単体テスト

・リスト14.4はどう動く? 基本コンストラクタ内のtestメソッドでテストを
  登録し、executeでテストが実行される?

・p239 L1最後の一文は?
  →14.4 内で、テストメソッドを実装する場合は、14.3と同じになる、ということ?
    (1意見) test("xxx xxx xxx")と書くと、暗黙でxxxXxxXxxメソッドが定義
    されるのかと思った。

■14.3 情報が豊富なエラーレポート

・expectをJavaで書いたらどうなる?
  → 例えば:
     expect(2, new ExpectFunction<:Integer>() {
       @Override
       Integer execute() {
         return ele.getWidth();
       }
     });
     長い……。

■14.4 JUnitとTestNGの使い方

・p241 下のリスト
  2つ目の@Testの直後の{...}は、アノテーション@Testの引数相当。
  Javaで書くと、@Test(exceptedExceptions={...}) と同じ。

・p242 リスト14.6
  - テストの数は減っているのでは?
  - interceptを別メソッドにすればいい。p241よりは短かいコードになる

■14.5 仕様としてのテスト

・it should ～と英語で読める。
・IAE = IllegalArgumentException。
・specs → やりすぎではないか?
・自然言語 = 英語
  日本語でも定義できるのでは?
・自然言語に近付けば近付くほど、あいまいにならないか?

■14.6 プロパティベースのテスト

・「数百のwの値」は適切な値が生成されているか?
  wとして適切な値が選ばれているか? ⇒ 宿題
・境界値は判断してくれるのか?
・文字列の場合はどうなるのか?

■14.7 テストの構成と実行

■14.8 まとめ

15章ケースクラスとパターンマッチ

■15.1 単純なサンプル

・simplifyTop自体は再帰するか? → しない。
・erlangのパターンマッチのOO的な表現?

■15.2 パターンの種類

・Javaではこうなる? (15.2.1の直後のリスト)
  if (expr instanceof BinOp) {
    op = expr.op;
    left = expr.left;
    right = expr.right;
    ...
  }

・変数パターンの特殊ケースがワイルドパターン?

・15.2.3 perlっぽい印象がある。

●次回は15.5から

[ 戻る ]