\documentstyle[twocolumn,alltt,fancybox]{article}
\setlength{\oddsidemargin}{-10mm}
\setlength{\evensidemargin}{-10mm}
\setlength{\topmargin}{-12mm}
\textheight=23.8cm
\textwidth=18cm
\date{}
\renewcommand{\ll}{<:}
\newcommand{\sll}{\prec:}
\newcommand{\sls}{<\hbox{\tt\#}}
\newcommand{\CR}
{\ovalbox{\ooalign{\hfill$\scriptstyle\hookleftarrow$\hfill\crcr}}}
\newcommand{\maru}[1]
{{\ooalign{\hfill$\scriptstyle#1$\hfill\crcr$\bigcirc$}}}
\title{The Theory of Objects(3)\\〜〜\ 概要\ 〜〜}
\author{児玉靖司\\東京理科大学理工学部情報科学科}
\begin{document}
\maketitle
\setcounter{section}{3}
\section{オブジェクトベース言語}
クラスベース言語の主たる特徴は Simula で全て表現されている。オブジェクトベース
言語の主たる原理は、最初 the Treaty of Orlando[114] に含まれている。

\begin{itemize}
\item オブジェクトベース言語は伝統的なクラスベース言語に比べ単純で、
柔軟性が高くなりやすい。

\item 多くのオブジェクトベース言語は Lisp、Smalltalk など人工知能コミュニティ
(これらは、特に柔軟性が高く、高い価値を持っている)に指向している
[11,31,32,78,80]。

\item 結果として、型つきオブジェクトベース言語(Emerald のようなシンプルな
ものや、Ceil と Omega のような最近のものを除いて)を設計しようとする試みは
ほとんどない。
\end{itemize}

\subsection{クラスなしのオブジェクト}
\begin{itemize}
\item Emerald や簡単なクロージャベース言語のようなもっとも簡単な形で
は、オブジェクトの概念と動的 dispach を提供するのみである。
型づけをする際には、オブジェクトタイプ、サブタイプ、subsumption を提供
する。

\item オブジェクトベース言語の基本的な特徴は、クラスがなく、各オブジェクト
を生成する construct が存在することである。

\item 以下のように定義する。
\begin{alltt}
ObjectType {\it Cell} is
  var {\it contents: Integer};
  method {\it get(): Integer};
  method {\it set(n: Integer)};
end;
object {\it cell: Cell} is
  var {\it contents: Integer:=0};
  method {\it get(): Integer} is
    return self{\it.contents} end;
  method {\it set(n:Integer)} is
    self{\it.contents:=n} end;
end;
\end{alltt}
この {\tt object} の定義により、タイプ $Cell$ と名前 $cell$ の単一オブジェクト
が生成される。

\item クラスがなくても「手続き」により、同じ形のオブジェクト集合を
生成することができる(呼び出された時はいつでも新しいオブジェクトを返す)。
そのような手続きは引数を持ち、フィールドを初期化する。
\begin{alltt}
procedure {\it newCell(m: Integer):Cell} is
  object {\it cell:Cell} is
    var {\it contents: Integer:=m};
    method {\it get():Integer} is
      return self{\it .contents} end;
    method {\it set(n:Integer)} is
      self{\it.contents:=n} end;
  return {\it cell};
end;
var {\it cellInstance: Cell:=newCell(0);}
\end{alltt}
そのような生成手続きは、不思議と Simula のクラスに似ている(パラメータと
実行本体を持つ)。{\tt new}の役割は手続き呼び出しで実行される。
\end{itemize}

\subsection{プロトタイプとクローン}
\begin{itemize}
\item 上でみたように手続きによりオブジェクトをする生成することができる。
しかし、オブジェクトをパラメータ化する際に、全ての可能な方法を予測する
ことは難しく実用的ではない。
\item いわゆるプロトタイプベース言語では、オブジェクトを生成する
ために別のアプローチを採用している。
\item あらかじめパラメータ付き (parameterizing) オブジェクトを定義する
代わりに、prototypical オブジェクトから stock objects を生成し、後で 
stock object をカスタマイズする。
\item プロトタイプベース言語では、最初具体的かつ関数的なインスタンスを
生成する。インスタンスのいくつかが後で、インスタンスのクラスの 
canonical representatives (プロトタイプ) として解釈される。
\item プロトタイプを instantiating する基本的メカニズムはクローンで
ある。クローンは、オブジェクトの shallow copy(浅いコピー) を生成する。
\item クローンは {\tt new} に似ている。
$$\hbox{\tt var}\:cellClone:\:Cell:=\:\hbox{\tt clone}\:\:cellInstance;$$
この処理は、クラスに対してでなくオブジェクトに対して行う。クローンされた
オブジェクトは「インスタンスとして」かつ「プロトタイプとして」振る舞う。
\item プロトタイプとしてのオブジェクトは、それから(オブジェクトを)クロー
ンするという意味で「クラス」のように振る舞う。かつそれから(プロトタイプを)
クローンするという意味で「スーパークラス」としても振る舞う。しかし、クラス
と異なり、プロトタイプ自身の right に基づいているという意味で関数的オ
ブジェクトである
\footnote{プロトタイプ言語のための $InstanceTypeOf(c)$ に等しいものが
ある。Cecil では $DescendentOf(o)$ で、複製されたオブジェクト(間接的
または直接的に)のタイプとしている。$DescedentOf$ の概念は実行時に
メソッドのパラメータを抑制する。}。
\item 以下のようにフィールドをカスタマイズすることができる。
$$cellClone.contents:=3;$$
\item より一般的に、メソッドを修正することによりクローンの振る舞いをカ
スタマイズしたいと思うかもしれない。オブジェクトの振る舞いを動的に修正
することは、オブジェクトベース言語におけるユニークな性質である。
\begin{alltt}
{\it cellClone.get :=}
  method{\it ():Integer} is
    if self{.contents}\(<0\) then return \(0\)
      else return self{.contents} end;
  end;
\end{alltt}
メソッド {\it get} を「負の数を返さないように」変更した。

\item メソッド update は、簡単にかつ静的に型付け可能であるという
利点を持つ\footnote{メソッド update はいくつかの言語(Beta、NewtonScript、
Obliq、Kevo、Granet)により提供されている。他の言語(Self、Act1)は、
動的に attribute を削除かつ追加することができる。また (Self、Ellie)は
メソッドのグループを置換することができる。}。

\item メソッド update をより詳しく説明するために、節 2.3 の例 $reCell$ を
修正する。
\begin{alltt}
ObjectType {\it ReCell} is
  var {\it contents: Integer;}
  method {\it get(): Integer;}
  method {\it set(n: Integer);}
  method {\it restore();}
end;
object {\it reCell: ReCell} is
  var {\it contents: Integer:=0;}
  method {\it get(): Integer} is
    return self{\it.contents} end
  method {\it set(n: Integer)} is
    let {\it x=} self{\it.get();}
    self{\it.restore:=} method {\it ()}
      is self{\it.contents:=x} end;
    self{\it.contents:=n;}
  end;
  method {\it restore()} is
    self{\it.contents:=}\(0\) end;
end;
\end{alltt}
{\it set} メソッドは {\it restore} メソッドを update している。
{\it backup} フィールドを設ける必要はなし。
\end{itemize}

\subsection{Embedding による継承と Delegation による継承}
Emerald のような簡単なオブジェクト指向言語は、共通する振る舞いを共有す
るために、オブジェクトを生成する「手続き」を使う。しかし、これらの言語は
継承メカニズムを持たない。
\begin{itemize}
\item プロトタイプベース言語は、生成メカニズムに加え、各オブジェクトを
update する方法を持っている。
\item クローンは継承としてみなすことができ、update は、
overriding とみなすことができる。しかし、クローンと update は、
プロトタイプの形を常に保っているという意味で、継承の十分な柔軟性を提供
するものではない。

\item 考慮すべき継承メカニズムは、オブジェクトに新しい 
attribute を拡張することである。オブジェクトの拡張は、しかしながら
簡単ではない。第一の問題は、現存する attribute と付加する attribute と
のクラッシュである。型付き言語には注意深さが必要である。
もう一つの問題は、オブジェクトの identity を扱うオブジェクトを拡張する
ために、その表現 (representation) を update する必要があることである。

\item 現存するオブジェクトを拡張するもう一つの方法は、現存する 
attribute を含んだ新しいオブジェクトを構築することである。これは、プロ
トタイプベース言語でよく知られた継承メカニズムである。

\item プロトタイプ言語において継承に対して 2 つの直交した見方がある。
donor オブジェクトの attribute を扱うか、新しいホストオブジェクトにそ
れら attribute を導入するかである。
これらの次元に沿って、プロトタイプ言語は 4 つのカテゴリに分割すること
ができる。

\item donor オブジェクトの attribute は、implicitly または explicitly 
に扱うか。これらの attribute は ホストオブジェクトに embedded されるか、
または donor から delegated されているかである。

\item implicit 継承では、一つまたは複数のオブジェクトが 
donor として設定され、かつそれらの attribute は implicitly に継承される。

\item explicit 継承では、一つまたは複数の donor の各 attribute は
explicitly に設定される。

\item 継承においてより重要な区別は、embedding と delegation の区別であ
る。embedding では donor から継承された attribute は、ホストオ
ブジェクトの一部となる。delegation では、継承された attribute は
donor の一部として残り、ホストオブジェクトから間接参照される。

\item embedding、delegation の両方において {\tt self}(の意味づけ)は、
しばしば出現する。original の receiver オブジェクトである。2 つの継承
の形の意味の違いにより、どのように donor オブジェクトの変化がホスト
オブジェクト (attribute を継承する) に影響を与えるかを考察する。
embedding では、ホストオブジェクトは donor オブジェクトと独立している。
delegation では、複雑な(クモの巣のような)依存関係が生成される。

\end{itemize}

\subsection{Embedding}
継承の一つの可能な解釈は、ホストオブジェクトが donor オブジェクトの 
attribute の複製を含んでいることである。これを、継承の embedding 解釈
または、単に embedding という(図4-1)。
\begin{itemize}
\item embedding は「呼び出しの受側」として {\tt self}の標準的意味を
最も簡単に説明することができる。embedding 解釈
において、継承メソッド呼び出しは、ちょうど original メソッド呼び出しを
意味する。

\item embedding はプロトタイプベース言語において最初の提案の一つであっ
た。最近では単に Kevo と Obliq のような言語に適用されているだけである。
このような言語を embedding ベースという。

\item 前節で説明したように、継承は explicitly または implicitly に
区別することができる。embedding 継承の explicit な形は、古いオブジェク
トの一部分を新しいオブジェクトに reassembing するものとして考えること
ができる。embedding 継承の implicit な形は現存するオブジェクトのクロー
ンを新しい attribute と共に拡張する方法である。

\item embedding の explicit バージョンでは、指定したオブジェクトから、
メソッドとフィールドを複製する。例えば、回復可能 $cell$ は以下のようになる。
\begin{alltt}
object {\it cell: Cell} is
  var {\it contents: Integer := 0;}
  method {\it get(): Integer} is
    return self{\it.contents} end;
  method {\it set(n: Integer)} is
    self{\it.contents:=n} end;
end;
object {\it reCellExp:ReCell} is
  var {\it contents: Integer:=cell.contents;}
  var {\it backup: Integer:=0};
  method {\it get(): Integer} is
    return embed {\it cell.get()};
  end;
  method {\it set(n:Integer)} is
    self{\it.backup:=} self{\it.contents;}
    embed {\it cell.set(n);}
  end;
  method {\it restore()} is
    self{\it.contents:=} self{\it.backup} end;
end;
\end{alltt}
\item {\tt embed} $o.m(\cdots)$ と書いてオブジェクト $o$ のメソッドを
現在オブジェクトに embed する。この embedding コンストラクトにより、
$get$ メソッドの implicit 継承と $set$ メソッドでの {\tt
super}$.set(n)$ の出現の両方を入れ替えている。

\item {\tt embed }$cell.set(n)$ の意味は $cell$ の $set$ メソッド
(現在の「自身」を意味する {\tt self}を伴った)を実行する。$set$ のコード
を $reCellExp$ に embeded し、$cell$ オブジェクトには影響を与えない。

\item $get$ メソッドのコードはより冗長である。以下のように省略して書く
ことができる。\begin{center}{\tt method}\ {\it get}\ {\tt copied
from}\ {\it cell}\end{center}
しかし {\tt embed} コンストラクトはまだ必要である。

\item 型づけの問題を避けるために、{\tt embed} に続くオブジェクト
(そのタイプではなく、オブジェクトそのもの)は、静的に知らなければならな
い。この意味において、状況はサブクラス定義(スーパークラスは静的に知ら
なければならない)に似ている。

\item embedding の implicit バージョンでは、新しいオブジェクトに複製さ
れるべきメソッドとフィールドの donor としてあるオブジェクトを設定する。
例えば、回復可能な $cell$ の例は以下のようになる。
\begin{alltt}
object {\it cell:Cell} is
  var {\it contents: Integer:=0};
  method {\it get():Integer} is
    return self{\it .contents} end;
  method {\it set(n: Integer)} is
    self{\it .contents:=n} end;
end;
object {\it reCellImp: ReCell} extends {\it cell} is
  var {\it backup: Integer:=0;}
  override {\it set(n: Integer)} is
    {\tt self}{\it .backup:=}self{\it.contents;}
    embed {\it cell.set(n);}
  end;
  method {\it restore()} is
    self{\it .contents:=}{\tt self}{\it .backup} end;
end;
\end{alltt}
これらの定義は、節 2.1 と 2.3 の(対応する)クラス定義とは大変異なってい
る。

\item {\tt extends} 宣言は {\it reCellImp} のための donor オブジェクト 
$cell$ を表わす。{\tt extends} に続くオブジェクトは静的に知っていると
仮定する。この宣言の結果として、$reCellImp$ は $cell$ の attribute の
複製(状態は$cell$ とは異なる)を含むオブジェクトとなる。

\item {\tt override} の効果は、ホスト側で donor にあるメソッドを置換する。
{\tt embed} コンストラクタはまだ必要である。

\item オブジェクトは donor オブジェクトとは独立しているため
{\it reCellImp} と {\it reCellExp} の定義は、スタンドアロン定義では
以下のように省略することができる。
\begin{alltt}
object {\it reCell: ReCell} is
  var {\it contents: Integer:=0;}
  var {\it backup: Integer:=0;}
  method {\it get(): Integer} is
    return self{\it.contents} end;
  method {\it set(n: Integer)} is
    self{\it.backup:=} self{\it.contents;}
    self{\it.contents:=n;}
  end;
  method {\it restore()} is
    self{\it .contents:=}self{\it .backup} end;
end
\end{alltt}

\item また、以下のように定義することも可能である。
\begin{alltt}
object {\it reCellImp1: ReCell} extends {\it cell} is
  var {\it backup: Integer:=0;}
  method {\it restore()} is self{\it .contents:=}
    self{\it .backup} end;
end;
{\it reCellImp1.set:=}
  method {\it (n: Integer)} is
    self{\it.backup:=} self{\it.contents;}
    self{\it.contents:=n;}
  end;
\end{alltt}
\end{itemize}

\subsection{Delegation}
\begin{itemize}
\item オブジェクト間で attribute を共有することができるプロトタイプベー
ス言語は delegation ベースという。delegation は、オブジェクトやプロト
タイプから、フィールドへのアクセスやメソッド呼び出しを他のオブジェクト
へ間接的に処理することである。結果として、オブジェクトがもう一つのオブ
ジェクトの拡張であるように見えるようにする。

\item implicit delegation 継承 [49,121] の最もよく知られた形は、子オブ
ジェクト(ホストオブジェクト)が、もう一つのオブジェクトを親オブジェクト
(donor)とすることである。

\item 実装として、親の attribute を持つことができ(図4-2)、子が親へのリ
ンク (parent link) を持つことである。オブジェクトに親の 
attribute がない場合は、親を検索する。

\item 以下のように $cell$ の子として $reCellImp'$ を定義する。
\begin{alltt}
object {\it cell: Cell} is
  var {\it contents: Integer:=0;}
  method {\it get(): Integer} is
    return self{\it .contents} end;
  method {\it set(n:Integer)} is
    self{\it .contents:=n} end;
end;
object {\it reCellImp':ReCell} child of {\it cell} is
  var {\it backup: Integer:=0;}
  override {\it set(n: Integer)} is
    self{\it.backup:=} self{\it.contents;}
    delegate {\it cell.set(n);}
  end;
  method {\it restore()} is self{\it .contents:=}
    self{\it.backup} end;
end;
\end{alltt}
\item {\tt super}{\it.set(n)} と書く代わりに
{\tt delegate}\ {\it cell.set(n)} と書く。{\tt delegate}\ 
{\it cell.set(n)} は、現在の self に束縛された {\tt self} を持つ
 $cell$ の $set$ メソッドを実行する。

\item {\tt delegate} と {\tt embed} の違いは、前者が、メソッド呼び出し
の時に、親からメソッドを手に入れ、後者はより早く、オブジェクト生成時
に(親からのメソッド)を手に入れることを示す。

\item $reCellImp'$ の定義は、embedding の $reCellImp$ の定義
(節 4.4)と似ている。しかし、意味は異なる。{\it reCellImp'} は $cell$ 
の attribute の複製を含んでいない、しかしその代わり親へのリンクを持っ
ている。親へのリンクにより $cell$ オブジェクトの attribute は、全て
の子によって共有される。それゆえ、上の $reCellImp'$ は間違いである。一
つの $contents$ フィールドは、$cell$ の子かつ $reCellImp'$ のクローンによ
り共有する。

\item 回復可能な $cell$ のよりよい定義は、親の {\it contents} フィール
ドを overriding するローカルの複製が必要である。
以下のように $reCellImp$ を定義することができる。
\begin{alltt}
object {\it reCellImp: ReCell} child of {\it cell} is
  override {\it contents: Integer:=cell.contents;}
  var {\it backup: Integer:=0;}
  override {\it set(n: Integer)} is
    self{\it.backup:=} self{\it.contents;}
    delegate {\it cell.set(n);}
  end;
  method {\it restore()} is self{\it.contents:=}
    self{\it.backup} end;
end;
\end{alltt}

\item delegation 継承の重要な見方は {\tt self} を持った
親へのリンクとの干渉である。$reCellImp.get()$ の呼び出しにおいて、
$get$ メソッドは親 $cell$ にだけ存在する。しかし、$get$ コードの中に
ある {\tt self} の出現は original の受側を指す(親 $cell$ ではない)。

\item よって $get()$ の返値としては $reCellImp$ の $contents$ フィー
ルドに格納されている整数が望まれる。

\item embedding では、子が delegation により構築された時は、
その親は静的に知ることができると仮定する。このような制約は、静的に型
付けされた delegation ベース言語(Cecil のような)に適用することができる。
子が親との適合性をチェックすることが重要である。

\item 親のタイプを知るだけでは、健全性のためには十分ではない。例えば 
{\it cell} の {\it contents} フィールドが subsumption により忘れさられ、
子が タイプ $Boolean$ の $contents$ フィールドを持って定義されたとする
と、子を通して呼び出される時に、継承された $get$ メソッドは original 
の受側としての {\tt self} を解釈するために  $Boolean$ を返す。
この結果は、間違いである。なぜなら $get$ メソッドの結果タイプは 
$Integer$ だからである。

\item より一般的に、親が「真のタイプ」を静的に知っていても、どの
オブジェクトかを特定できないかもしれない。他方、親がある attribute を
持たないことを静的に知らないに違いない。これらのオブジェクトは洗練され
たタイプシステムにより実行されうる。ここでは単に親オブジェクトは静的に
知ることができると仮定する。

\item 次に explicit delegation 継承を概観する。そこでは、オブジェクト
は独立したメソッドを explicitly に他のオブジェクトに delegate し[80]、
親の宣言はない\footnote{Ellie は explicit embedding と 
explicit delegation を持っている。Self は原則的には implicit
delegation であるが、explicit delegation の primitive も提供している。}。
以下のように書く。
\begin{alltt}
object {\it reCellExp: ReCell} is
  var {\it contents: Integer:=cell.contents;}
  var backup: Integer:=0;
  method {\it get(): Integer} is return
    delegate {\it cell.get()} end;
  method {\it set(n: Integer)} is
    self{\it.backup:=} self{\it.contents;}
    delegate {\it cell.set(n);} end;
  method {\it restore()} is self{\it .contents:=}
    self{\it.bakcup} end;
end;
\end{alltt}

\item explicit delegation は、複数のオブジェクトへ操作を delegate する
clean な方法を提供する。

\item 複数 delegation は、複数の親をリストすることにより、時々 
implicit delegation モデルでも提供される。implicit multiple 継承の場合は、
曖昧なメソッド lookup を引き起こすために問題がある。複数の親は 
explicit delegation により明らかに表現されなければならない。

\end{itemize}

\subsection{Embedding vs. Delegation}
\begin{itemize}
\item embedding 継承においては、新たに生成されたホストオブジェクトは 
donor attribute の複製を持っている。継承された donor attribute にアク
セスするためには、original の attribute にアクセスするのとなんら違いが
ない。

\item delegation 継承(ホストオブジェクトは 外部の donor オブジェクト
へのリンクを持つ)では、状況はそんなに簡単ではない。メソッド呼び
出しの際の attribute lookup 手続きにより {\tt self} が original の受側を
示すようにしなければならない。この要求は、実現と method lookup のフォー
マルモデリングの両方を複雑にする。

\item クラスベース言語では embedding と delegation モデルは通常同じも
のである。オブジェクトベース言語では区別される。

\item 一般に delegation での donor の性質の共有は、いくつかの
方法に分けることができる。

\item delegation では donors は update されるかもしれないし、フィールドを含
んでいるかもしれない。変更は、inheriting ホストに見られる。

\item 同じように、donor のメソッドは update されるかもしれない。
変更は inheriting ホストに見られる。

\item donor へのリンクはしばしば、オブジェクトにある他のリンクへと置
換されるかもしれない。そのオブジェクトの全ての inheritors は、振る舞い
を変更されるかもしれない。

\item クローンは、オブジェクトの shallow コピー(donor のコピーをしない)
を処理する。そして全てのクローンは donor、mutable フィールドと donor 
のメソッドを共有するようになる。

\item このように embedding と delegation は、プロトタイプを継承する際
に 2 つの根本的な方法の違いがある。両方の可能性を持つ興味深い言語があ
る。

\item delegation は 2 つの内でもっとも知られた方法である。delegation 
の利点は、オブジェクトの 全ての inheritors の予期しない変化を処理する
のに便利なことである。

\item delegation を非難するとすれば(壊れやすいシステムになるような)依
存関係の 動的な web を生成することである。embedding はこの問題に影響を
与えない。なぜならオブジェクトは自立的であるからである。

\item Kevo や Omega のような embeddingベース言語では、予期しない変化に
対しては(donor 階層なしのように)達成される。

\item 共有による space 効率化は、delegation メカニズムの主な動機
の一つである。

\item delegation ベース言語でさえ、透過に共有する構造を使ってクローン
演算を最適化している。同じ技術により embedding ベース言語の space
利用は最適化されうる。

\item 結果として「オブジェクトベース言語での継承のための最良のモデ
ルは何か」の問いはまだ、オープンである。

\end{itemize}

\subsection{動的継承とモードスイッチ}
delegation 継承では、親へのリンクが固定される時、静的という。
また、親へのリンクは動的に update される時、動的という。
\begin{itemize}
\item delegation ベース言語 Self では、例えば親へのリンクは変数として
宣言され、オブジェクトの親は動的に他のオブジェクトと置換することができ
る(図4-3)\footnote{逆に、Cecil は静的 delegation を提供している 
delegation ベース言語である。}。動的 delegation は「動的継承」ともいわ
れる。

\item 動的継承は、一般的に危険な特徴であるが、むしろエレガントで 洗練
されたプログラミング技術である。

\item モードスイッチ (mode-switching)(親は、同じ attribute を持った別
のオブジェクトと置換される)は、動的継承の特別な場合である\footnote{親
の階層構造が、プログラムを格納するために階層的名前空間として使われる
時 (Self 環境にあるように)、古い親と新しい親とに関係は必要ではない。}。

\item モードスイッチの例として、アイコン化(モード)とオープン(モー
ド)ウインドウを表現するオブジェクトを考えることができる。ウイン
ドウキャンバスサイズとアイコン picture は、アイコン化と非アイコン化の
処理において保存される(同じである)。両モード共に、ウインドウは、描かれる 
picture を記録する。ウインドウは、モードに依存して異なった
反応をする。例えば、drawing primitive は on-screen と off-screen を切
り替え paint するかもしれない。

\item モードの切り替えは、親の切り替えにより処理することができる。
各親は、一つのモードの状態と振る舞いをカプセル化している。

\item 一般に、同じ働きをするモードスイッチは、各メソッドのコードの中に
フラグを挿
入することにより処理することができる。フラグを切り替えることにより、モー
ドを切り替えることができる。しかし、この解はフラグとモードが複数となった
場合、扱いにくいものとなる。

\item さらに、フラグを使った解は、閉じた世界(全ての表現
や、将来追加されるであろうモード)を仮定することになる。ここでの親を切
り替える技術は、現存しているコードを変更することなく、新しいモードを追
加することができる。

\item delegation ベース言語において使われるモードスイッチは、動的に親
を変更する機能である。

\item モードスイッチの例として、節 4.5 のオブジェクト $reCellImp$ の
新しい親 $cell':Cell$ を与える。
\begin{center}{\tt reparent} {\it reCellImp}\ {\tt to}\ {\it cell';}
\end{center}
これは $reCellImp$ の親リンクを変更している($cell$ を $cell'$ に変更)。
これから $reCellImp.get()$ の呼び出しは $cell$ の$get$ メソッドの代わりに 
$cell'$ のそれを呼び出すことになる。

\item モードスイッチの影響と似たものは、メソッド update により達成する
ことができる。例えば、節 4.4 の embedding モデルにおいて $reCellImp$ の親
を $cell'$ へ変更する。以下のように書くことができる。
\begin{alltt}
{\it reCellImp.get:=}
  method {\it (): Integer} is
    return embed {\it cell'.get()} end;
{\it reCellImp.set:=}
  method {\it (n:Integer)} is
    self{\it.backup:=} self{\it.contents;}
    embed {\it cell'.set(n);}
  end;
\end{alltt}
\item このように embedding モデルでのメソッド update により (delegation 
ベースを含む) 動的継承のアプリケーションをエミュレートする能力をもつ。

\end{itemize}

\subsection{特色(Trait):プロトタイプからクラスへの逆戻り?}
プロトタイプとクローンは、クラスとインスタンスに代わるものであった。
\begin{itemize}
\item いくつかのプロトタイプベース言語は、クラスに似た構造をベースとし
た、より伝統的なアプローチに向かった。
\item Self と Cecil のような delegation ベース言語は {\it traits
objects}、{\it prototype objects}、{\it normal objects} を区別している
\footnote{この用語は、Self からである。Cecil は、同じように、順に 
abstract、templete、concrete オブジェクトを提供している。Cecil は静的に
型付けられた言語なので、これらの区別は Self よりはっきりしている。
Omega は プロトタイプとクローンの間で違いがある。}

\item Self と Cecil では traits と prototypes は共にクラスをエミュレー
トするために使われる。traits は、通常メソッドを持っている。prototypes 
は通常 フィールドを持ち、親のための traits を持つ。

\item normal オブジェクトは prototype からクローンされ prototypes の 
traits を共有する(図4-4)。いくつかの traits は、多重継承の形において
単一 prototype により使われるかもしれない。

\item クラスレス言語の精神により traits と prototypes はまだ通常のオ
ブジェクトである。しかし、それらは役割の分担がある。traits は normal 
オブジェクトの親として共有される傾向がある。それらは直接使われること
なく、複製されるべきではない。

\item プロトタイプは、クローンによりオブジェクト(プロトタイプ)の生成を
処理する傾向がある。それらは、直接アクセスまたは変更されるべきではない。

\item normal オブジェクトは、単に局所的状態を格納するために使われる。
メソッドは traits に依存すべきである。

\item traits と prototype の役割を区別することは、delegation context 
において役に立つが、プロトタイプアプローチの精神を破壊するもので
ある[59]。

\item traits は normal オブジェクトの intended attributes の一
部を含んでいる。一般に traits のメソッドは、プロトタイプに含まれる フィー
ルドを参照している。不完全な traits は、機能しない。これは(各オブジェ
クトは振る舞いに対して self-contained exemplar であるべきである)
original のプロトタイピングアイデアからはかけ離れている
\footnote{Omega は、プロトタイプとクローンの区別を強いるが、プロトタイ
プのアイデアに対して、完全なオブジェクトである。}

\item それゆえ traits は「全てはオブジェクトである」という世界でも
ordinary オブジェクトとしてみなすことは難しい。
traits は 型付き言語では normal オブジェクトとして使うことはできない。
また、それらのプロトタイプと共に特別に型づけされる必要がある。

\item 結果として traits はクラスの性質の多くを含む。

\item traits と他のオブジェクトを区別することにより、クラスベース言語
に逆戻りし、クラスとインスタンスを区別したようにみえるかもしれない。
事実 delegation ベース言語において traits とプロトタイプを区別するこ
とは、ちょうどクラスのための実現上の技術(implementation technique) の
ようである。Cecil と Omega は、動的継承をあきらめることによりクラスベー
ス言語に近づいている。

\item このように、オブジェクトベース言語ではクラスベースの概念と技術は、
禁止されているわけではない。むしろ programming convention として、言語
構造の中に強いて再構築している。オブジェクトベースとクラスベースの間の空間は、
連続体として表現されるべきである[114]。オブジェクトベース言語の目標は
「クラスは共通の性質を持ったオブジェクトを生成する方法のうち(可能なも
のの)一つであることを明らかにすることである。オブジェクトはクラスより 
primitive であり、クラスより先に理解され、説明されるべきである。

\end{itemize}

\subsection{オブジェクトベース言語のためのタイプ}
\begin{itemize}
\item 多くのオブジェクトベース言語は、動的 delegation のような、動的な
特徴に依存している。静的タイプシステムでは(fully) 扱うことができない。

\item 型なし手続き型言語では、このような極端な適応性は、適当な型システムを追
加することにより修復することができる。

\item 2, 3 の型付きプロトタイプベース言語が、現在では注目されている。

\item Cecil と Omega のようなプロトタイプベース言語での型付けは、動的な
特徴を極端に制限している。それらの型づけとクラスベース言語で使われたそ
れとの違いはあまりない。それゆえ、クラスベース言語でのタイプの議論(2 章
と 3 章) の多くは、静的に型付けされたオブジェクトベース言語に
適応する。

\item しかし、独特な型づけ問題も残る。第一に(制限なしの動的継承とは反
対の)モードスイッチはむしろ簡単に型づけすることができる\footnote{オブジェ
クトベース言語におけるタイプチェッキングモードスイッチの可能性は、
新しいアイデアのようにみえるかもしれない。モードスイッチは、Cecil と 
Omega ではルール化されている。}。

\item 第二に、オブジェクトベース言語のためのメソッド specialization 
と Self タイプは考察が必要である。

\item 節 2.7 と 2.8 では、クラスベース言語において、どのように メソッド 
specialization と covariant {\tt Self} を扱うかを議論した。
contravariant {\tt Self} はより問題がある。節 3.5 では subsumption を
あきらめて、再帰型を protocols として定義しなければならなかった。

\item 動的継承を持ったオブジェクトベース言語では covariant {\tt Self} 
も議論する必要がある(メソッドが update されるかもしれない)。
結果タイプ {\tt Self} を持った updating メソッドを
許すことができることに驚くかもしれない。Contravariant {\tt Self} は、
protocol メカニズムを用いて扱わなければならない。

\item これらの問題は、Part II と III で広く議論する。

\end{itemize}

\section{オブジェクト指向言語のモデル化}
前章では、オブジェクト指向の特徴を多く、比較的公平に表現した。これら
の特徴のモデル化の方法について議論する。

\subsection{基本的なメカニズムへの還元}
\begin{itemize}
\item いくつかのオブジェクト指向の特徴の間での違いと、類似点を議論した。
クラスベースとオブジェクト指向言語の特徴の多くは 2,3 の一般的なアイデアの表
現の違いであるということができる。これらの表現の違
いは、単一の概念的でかつフォーマルフレームワークに統合できるかとい
う自然な問いが発生する。

\item 単一フレームワークを持ったオブジェクト指向言語のバラエティーを
囲む可能な方法が 2 つある。一つ目のアプローチは、オブジェクト 
classification と継承についての(全ての)考えられるバラエティー
を表現することができる、オブジェクトモデルを作ることである。
そのようなモデルは作れるかもしれないが、その「複雑さ」または表現の一般性
によりあまり役にたつわけではない。

\item 他のアプローチとしては、より複雑な概念を表現し、十分に柔軟的で簡単
なモデルを作ることである。しかし、ある特定言語に直接実装できるもので
はない。これは($\lambda$ 計算を使って)手続き言語のより多くの理解の結果
解決できる。この本ではオブジェクト指向言語のために適合したアプローチを
提供する。節 6.7 と 18 章で議論するように、$\lambda$ 計算はオブジェク
ト指向言語のための基礎として完全ではない。$\lambda$ 計算をオブジェク
ト計算に置換することにより、望まれたモデリングパワーを得ることができる。

\item 我々が開発したオブジェクト計算は $\lambda$ 計算の抽象と同じレベ
ルのフォーマリズムである。$\lambda$ 計算の開発にあるように、我々は最小
の型なし(関数ではなくオブジェクトをベースにしている)カーネルから始め、よ
り構造を付け加えて、言語の特徴が実際にモ
デル化されうるまで、洗練されたタイプシステムにしていく。この本のコース
では、関数と命令型実行モデルの両方について、型なし、簡単タイプ、多相計
算を議論する。オブジェクト primitive のよく知られたカーネルは、計算
全てのファミリーの概念的合体を提供する。

\item オブジェクト計算は、クラスベースとオブジェクトベース言語を基本的
なメカニズムに削減した結果としてみることができる。クラスベース言語は、
多くのアイデアを単一の構造(クラス)に統合している。クラスベース言語を理
解し、解析するための多くの努力は、それらのアイデアの違いを区別すること
である。

\item オブジェクトベース言語は、クラスベースの特徴を簡単化するために分
解し、異なった方法でそれらを再構築することである。

\item 我々の開発では、オブジェクトベース言語をオブジェクト計算
に分解する。original のオブジェクトベースまたは、クラスベースの特徴の
模倣は、直接的でなく、便利ではないかもしれない。生の表現力は、しかし、
同じである。

\end{itemize}

\subsection{メソッド update の役割り}
\begin{itemize}
\item 最小限のオブジェクト計算により、オブジェクトをメソッドの集まりと
することが自然であるようにみえる。

\item フィールドも重要である。しかし、導出された概念としてみることがで
きる。例えば、フィールドは self パラメータを使わないメソッドとして表
わすことができる。

\item フィールドとメソッドを同一視することにより、片方からもう片方に変
換することがしやすくなる。その変換は概念的には passive データを active
computation に変更すること、そしてその逆である。

\item フィールドをメソッドと統合することは、簡単化のために利点をもたら
す。オブジェクトとオブジェクト演算は、単一の構造を仮定することができる。
逆に、
フィールドとメソッドの区別は、オブジェクト演算の区別と一致し、そして、
self の implicit または、explicit な区別を 2 つのコンポーネントに区別
することができる。フィールドをメソッドに統合することにより、コンパクト
になり、よりエレガントな計算となる。

\item しかし、この統合は、議論の余地がある。メソッドに対
する自然の演算はメソッド呼び出しであり、フィールドに対する自然な演算
は、フィールドセレクションとフィールド update である。フィールドとメソッ
ドを統合することにより、フィールドセレクションと、メソッド呼び出しを一
つの演算にすることになる\footnote{言語 Self はフィールド update と、メ
ソッド呼び出しを統合している。クライアントは、メソッド呼び出しのみ処理
する。しかし、オブジェクト内では、まだ、いわゆる data slots と 代入可能
slots を区別している。}。

\item しかし、メソッド update は、動的継承(オブジェクトの振る舞いの動
的修正)の一つの形としてみることができる。メソッド update は、
伝統的なクラスベース構造(そこでは、フィール
ドとメソッドは厳しく区別されている)をモデル化することができることに加え
て、オブジェクトベース構造をモデル化する上での edge である。

\item method update のより進んだ調整は、動的継承を使いならそうとする中
で見つけることができる。動的継承は、クラスベース言語にはない、オブジェ
クトベース言語のユニークな特徴である。

\item method update は、better-behaved mechanisms の一つである。静的に
型付け可能で、モードスイッチをエミュレートしうる。method update を使っ
て、動的継承で形のはっきりしない、危険な見方を避けている[59,119]。
一方、動的 specialization は、Treaty or Orlando[114] により支持さ
れたものである。

\end{itemize}

\subsection{この本の範囲}
\begin{itemize}
\item この本では、幅広く、しかし、普遍的ではない、オブジェクト指向構造
を扱う。クラスベースとオブジェクトベース言語を考察し、関数型と命令
型、型付きと型無しのそれぞれを考察する。

\item 前章では、多くのオブジェクト指向の特徴として
2 つの基本的なアイデア embedding と delegation を識別した。
オブジェクトの形式化では、主なオブジェクト指向パラダイムとして 
delegation より embedding を選択する。このアプローチは unconventional
であるが、それが最も簡単なフォーマルシステムを生じ、多くの特徴を表現するこ
とができる。

\item 例えば、我々の計算はクラスベースではない(クラスは built-in で
はない)が、クラスをモデル化することができる。それらは、モードスイッチ
の形で動的継承を含んだ embedding ベースの特徴を直接にモデル化すること
ができる。

\item delegation ベースにおいても、我々の計算ではクラスと同じくらい
簡単に traits をモデル化することができる。そして traits をベースにし
た 動的 delegation をモデル化することができる。

\item trais を通常のオブジェクトとして解釈することにより、重要な複雑さ
が生じる。delegation におけるメソッド lookup の複雑さのためである。そ
れゆえ、我々は、ある delegation ベース言語のこの見方を
簡単に説明することができない。

\item オブジェクトとしての traits の使用は、本質的ではない。そして、
型づき言語では徐々に廃止される。


\item 一般に、我々のフォーマルな扱いは、逐次言語にかつ、
各メソッドが、むしろ複数オブジェクト (multiple-dispatch) に属するもの
ではなく、単一オブジェクト (single-dispatch) に属する言語に制限されて
いる。

\item ある実行モデルの排除は、我々の目的にとってあまり重要ではない。オ
ブジェクト指向言語の型づけの性質を学ぶことにおいて、実行モデルは、関数
的、関係的、命令的、並行的とは、あまり関係ない。

\item 我々はこのことを同じようなタイプ構造を持つ関数型と命令型計算を扱
うことにより論証する。

\item 同じタイプ構造は、関係言語[13]と並行言語[20]に適用することができ
ることが立証されている。関数型と命令型の実行モデルは、区別して取り扱う。

\item 命令型計算に対して開発したが、我々が主に強調したいのは関数型計算に
おいてである。オブジェクト指向プログラミングの鍵となるアイデアの一
つは、(プライベートな)状態を隠すことと、非関数的概念であるため
変に感じるかもしれない。

\item 各命令型言語は関数型言語を含んでおり、命令型プログラムの型づけは
少なくとも関数型言語と同等である。

\item それゆえ、関数型計算を研究することは適当で、命令型言語に独特な
タイプ規則を追加することは、重要な複雑さを引き起こすものではない。

\item single-dispatch に制限することはより重要である。multiple-dispach 
を扱うことはオブジェクト指向言語の意味論と同様に large impact を持つ。

\item 現在では、オブジェクト指向言語の大多数は、single-dispatch に基づい
ている。型付きオブジェクト指向言語に対して、2,3 の multiple-dispath を
適用させた試みがある。

\item 次章以降では、オブジェクトのフォーマルな扱いを進めるにあたって、オ
ブジェクト指向言語のさまざまな特徴をモデル化する問題に、定期的に戻る。
\end{itemize}

\end{document}
