Scala の抽象データ型構築レシピ ver.2

前回の記事[1] は1日経ってみたら思い直すところがあり、以下のように修正した。

---

* Scala における抽象データ型構築レシピ

1. データ型のインターフェイスを決める。

2. 1で決めたインターフェイスの要素を以下の2種類に分類する

a. 当該データ型の値に対する何らかの操作。
b. 無から当該データ型の値を生み出すもの。定数。

3. 2で分類した a をメソッドとする abstract class を定義する。コンテナのように任意のデータ型に対して適用されるものの場合は型変数を付与する。以降この型変数を T とする。

4. 2で分類した b にあたるものを 3 のクラスを継承したクラスとして定義する。ここでデータ型が型変数を含まないならばこれをクラスではなく object としてよい。

5. 非定数について 3 のクラスを継承して実装を与える。

型変数があり、その型変数に特に制約（ [T <: X] のような形）を付けていなければ次の作業を行う。

6. これまでに定義したクラスの型変数を T から +T に変える。

7. 引数に T が現れるメソッドについて以下を行う。

a. T よりも上位（クラス階層図での上）の型 U を考えて メソッドに [U >: T] という型変数を付ける。
b. 引数の T を U に変える
c. 戻り値の T を U に変える

8. 2 で b に分類した定数に対応するクラスを obect に変える。ここで継承元のクラスの型変数は Nothing にする。

---

まず2の段階で「当該データ型の値から情報を抽出」と「新しい値を生み出す」を区別していたのをやめて a として統一した。前回の版ではこの区別を 7 の作業と結び付けていたのだが、よく考えると 7 の作業はその段階でのメソッドのシグニチャの字面から決まるものであって意味的な区別とは関係が無く、端的に間違っていた。

[後で例を追記]

それと前回悩んでいた 6 以降に進める基準は上述の書き方で事実上成立すると思う。「型変数に制約がついていても実は 6 以降に進める」ケースは2つ思いつくのだけどたぶんその２つとも実用上の用途はないと思われるからだ。

1つは元の型変数に対する制約が [T >: X] 　だった場合で、これはそもそもこういう制約を付けたいケースがたぶんない。もう一つは 制約が [T <% X] だった場合で、これは [2] のコメント欄に書いたようなやり方で手順を全うできるが、そのようにして作った型が特に有用になるケースが思いつかない。

[1] http://blog.so-net.ne.jp/rainyday/2007-09-04
[2] http://blog.so-net.ne.jp/rainyday/2007-08-08