Interlude - Smalltalker would NOT read the manuals ?

[ Updated: Sep 17, 1996 ]


序奏 (アダージョ)

従来のソフトウェア開発は、ウォーターフォールと呼ばれる直線的で後戻りの出来ないモデルをベースにしていました。昨今では、それが、

オブジェクト指向のソフトウェアを,クラスライブラリとして整理し,作り込んで,再組織化し,進化していく側面に注目すれば,以下の四つの過程の螺旋的な繰り返し (スパイラル) として認識できる。
  1. 特殊化 (Refinement) 過程
  2. 組み立て (Composition) 過程
  3. 抽象化 (Abstraction) 過程
  4. 要素分解 (Factorization) 過程
やはり,ぴったりしないものや間違いを見つけ出し,排除し削減していくプロセスである。
と見做されているようです。そんなわけで、とりあえず、SmalltalkAgents を立ち上げて、 上記を掛けながらプログラミングすることをお勧めします。これは典型的な『螺旋の音楽』と言えましょう。スパイラルな過程には、スパイラルなバック・ミュージックを添え、ついでに、クリムトの後期の絵の複製でも飾っておけば、はかどるかも知れませんね。なお、 Virgin から 1985 年にリリースされている CDVDT101 は part.III に 4 分弱のカットがあり、お勧めできません。

フェルマータつき全休止。

提示部 (アレグロ・モデラート)

 私と共に Smalltalk プログラムを開発しているメンバは, Smalltalk に付いてくるマニュアルをいっさい見ない.プログラム・リストも出力しない.シーケンシャルなものの限界を認識し,関係構造が失われることを極度に嫌っている.マニュアルに書かれているものは,ブラウザを使ってすべて見ることができる.この前,報告と納品にためにプログラム・リストをレーザ・プリンタに出力した女性の Smalltalker が,実に三年ぶりだと言っていた.
残念ながら, Smalltalk は本から学ぶことができない。 Smalltalk を学ぶ方法は実習のみである。実は, Smalltalk プログラマは初心者よりマニュアルを読まない。それは,彼らがシステムをより知っているからというわけではなく,知りたいことを見つける方法を知っているからなのである。
Rather than reformatting and printing the comments and structure of the class library, we have chosen to leave that information to be browsed on-line, in the SmalltalkAgents world. Frankly, we have found that we seldom, if ever, made use of the Encyclopedia of Classes that accompanied all first-generation Smalltalks. When we need information about a particular class or method, we tend to need it while we are proframming, which means the environment is easier than finding it in the printed manual.

展開部 (アレグロ・アッサイ)

どうも、Smalltalk のパワー・ユーザ、ないし、Smalltalker と呼ばれる導師レベルの人々にとっては、マニュアルは不必要なもの、なくても構わないもののようです。そのわけを、青木淳猊下は以下のように説明されています。

 Smalltalk の初心者が決まって口にする嘆きがある.「マニュアルがないのですか?」とか「すべてのメソッドの仕様書はありませんか?」である.私はきっぱり「無い!」と言うことにしている.「プログラミング環境がマニュアルだ!」と付け加える. 7 年間の Smalltalk ソフトウェア開発の統計データから,メソッドあたりの平均ステップ数は 5 ステップから 10 ステップである(コメントを除く).メソッド(モジュール)毎に仕様書を書くことが,どれだけの意味を持つかが疑問視される.より高度に細分化され,再利用が進んでいるシステムでは,モジュール自身の仕様よりも,他のモジュールとのかかわり合い(関係構造)が重要である.関係構造は,紙に書いたシーケンシャルなマニュアルでは表現できない.たとえインデックスが備えられ,ポストイットが手元にあってもである.これを表現する現在の技術は「ハイパー・テキスト」であろう. Smalltalk では 1970 年代にこの技術をプログラミング環境に取り込んだ.その最たる例が「ブラウザ」である.

われらが中嶋睦月師も、以下のように語っておられます。

そんなわけで、われわれ初心者は、例えば以下のようにしてクラス・ライブラリを理解して行くことが求められています。叩けよ、さらば開かれん、というわけです。

 この教科書を使って皆さんにやってほしいことがあります。それは,ランチャーやブラウザのメッセージペイン (上部 4 つサブウィンドウのいちばん右端 )の黄ボタンメニューの中の senders と implementors を利用することです。この教科書で知ることができたメッセージの senders と implementors を捜すことによって,そのメッセージの一般的な利用の仕方や,そのメッセージを受信できる他のオブジェクトなどを知ることができます。Smalltalkのプログラマとしての優秀さと, senders と implementors の使い方のうまさとには,大きな関連があります。
戯歌 (アレグロ・モデラート・エ・カンタービレ)

Smalltalker 殺すにゃ刃物は要らぬ、停電一つあればよい。

戯歌 終わり

いや、実際のところ、ぐだぐだ言ってもしょうがない。 SmalltalkAgents に関しては現在のところ、邦文英文いずれのドキュメントも、その質はともかく、数量的には他の処理系に比べて貧弱なのは、まぎれもない事実です。いずれはみんなが参照できるマップができるかも知れません。が、今のところ、膨大なクラスの森を散策して、自分なりの地図を作って行くしかないのです。

ただやみくもに森の中を駆け回っても迷子になるのが落ちです。クラスの森は生物 (いきもの / なまもの) です。リリースのたびに、少しずつ、または大胆にその姿を変えていきます。それどころか、立ち上げたときと終了するときですら、同じ姿ではありません。迷子になるだけなら良いのですが、ハーバート・リーバーマン『魔性の森』になってしまっては元も子もありません。なにか手だてが、磁石になるものが必要です。なにが磁石になってくれるのか。コードブラウザですね。コードブラウザで見えるものは、システムそのものです。その辺のオンライン・ヘルプとは、ちゃんちゃらおかしくて比較になりません。オンライン・ヘルプは、参照しているヘルプが、その環境を正しく説明しているものという盲目的な信仰の上でしか成り立ちません。

ここで注意をひとつ。コードブラウザで 500 弱あるクラスを覗いているとき、あなたは SmalltalkAgents のシステムの「はらわた」を見ています。下手に書き換えると、「システムのはらわた」は「死霊のはらわた」になります。今のところは、自分で定義したクラス以外は、見るだけにしておいた方が後悔しなくて済みます。別にややこしい話ではありません。コードブラウザでどんなにいじくり回したとしても、save さえしなければよいだけのことです。たとえ save した結果システムの挙動がおかしくなったとしても、最悪、インストールし直してしまえば済みますが。

ほんの少しですが、 ShowTime プロジェクトでコードブラウザを使って、クラスの森の入り口を窺って見ました。もう一度、振り返ってみましょう。

再現部 (アレグロ・モデラート・マ・ノン・トロッポ)

こんなふうにやってみました。

  1. まず、ウィンドウにボタンを一個貼り付けました。これがクリックされたときの挙動をどこで定義したらよいでしょうか。

    このような設定は、どのメソッドで記述すればよいのでしょうか。レシーバはボタンです。#vsAutoConfiguration でボタンが生成されているので、それより後でないといけません。こんなとき、 Smalltalk ではいちいちマニュアルを開いたりしません。Smalltalk は Smalltalk で記述されています。その上、そのソースを見ることができます。それどころか、そのソースを変更することすらできます。

    コードブラウザでの ShowTimeWindow >> #vsAutoConfiguration メソッドを開きます。Operations メニューの、Message Senders で、#vsAutoConfiguration メソッドがどこから送られてくるのか見てみましょう。 11 個のメソッドから呼ばれているのが判ります。スーパークラスの UIWindow 関連のものが 2 つあるので、それを見てみます。なぜか。 ShowTimeWindow は、 UIWindow のサブ・クラスだから、です。ShowTimeWindow は、 UIWindow が理解できるメッセージは、すべて理解できるからです。 #vsAutoConfiguration メソッドは、#createComponent したあとで、呼ばれています。その後の #privateGUIBuilderCreateMethod は private という接頭辞が付いているのでやばそうです。両方に共通するメソッドで、なるべく後の方で呼ばれるものとしては、#createWindow メソッドがあります。よさそうなメソッド名です。しかも、ここに書くというのは、中嶋睦月師の折り紙付きです。

    各ボタン・コンポーネントが参照可能な場所ならばどこにでも書けるのですが、慣例的には、ウィンドウクラスの createWindow メソッド中に記述するようです。

  2. どうやってフィールドに現在時刻の文字列を表示させるのでしょうか。

    これは、フィールドが理解できる文字列表示のメッセージはなにかということと同じです。 StaticTextField クラスが理解する #textContents: はすぐ見つかると思います。これで、フィールドに時刻を表示してみます。ついでに、#vsAutoConfiguration メソッドを参考にフォントも変えてみます。PenState のインスタンスを作って、そいつに #textFont: と #textSize: を送っているところを見てください。行揃えメソッドは、StaticTextField クラスを覗いてみると判ります。このように、判らないところは、とりあえず該当するクラスとその周辺を探していると見つかるものです。

  3. 終了するときにユーザに確認したいんですが、どうしましょう。

    終了ダイアログは、固定文字列と、2 個のボタンを付けたウィンドウです。どのクラスを使えばいいのでしょうか。というわけで、コードブラウザで UIWindow クラスを開いて、Tree View を見てみましょう。いくつかそれらしいクラスが見つかります。Notifier か Prompter のどちらかでしょう。それぞれのクラスを見てみます。Prompter クラスでは user-interaction というカテゴリに prompt: というクラス・メソッドがあるので、これを試してみます。

        Prompter prompt: 'Are you sure?'
    
    うーむ、返答用のフィールドも付いてきちゃいました。おまけにウィンドウはリサイズ可能になっています。今度は Notifier クラスを見てみます。同じ user-interaction というカテゴリに prompt: というクラス・メソッドがありました。
        Notifier prompt: 'Are you sure?'
    
    こちらですね、探しているものは。

  4. Thread はどうやって動かしたらいいのでしょう?

    このコードは、Threrad クラスの "run:" メソッドの Senders を参照してひねくり出しました。 Thread クラスをコードブラウザで開いて、#run: メソッドの Senders を表示させると、そいつを呼んでいるメソッドの一覧リストが出ます。適当にそれらしいのを開いて中のコードを試してみて、ちゃんと動くやつを探すだけです。なに、どんなにいじくったって、壊れやしません。何度でも繰り返しますが、 Smalltalk では、こういう芸当ができます。Smalltalker がマニュアルを読まないというのは、おそらく、こういうことです。システム全域に渡るソースを、hypertext like に見ることができるのに、なんで紙のマニュアルが必要なの? ということなのでしょう

コーダ (モルト・アレグロ)

ShowTime プロジェクトでは、上記のような感じでクラスの森の入り口を覗き見してみました。たいへんに初歩的な上、上記の方法が正しいのか否かはイマイチ不安ですが、この「覗き方」を知っているのと知らないのでは、あとあとかなり違ってくるのではないかと思います。


Created: Sep 17, 1996