多くの言語ワークベンチでよくある機能の一つが、ソース編集システムではなく、プロジェクショナルな編集システムを使うこと。
ソースベースの編集システムは、編集可能な表現を使ってプログラムを定義する。
実際にはその表現はテキストで、プログラムは読まれてどんなテキスト編集ツールでも編集できることを意味する。
このテキストはプログラムのソースコードである。
ソースコードをコンパイラやインタプリタに与えることによってそれを実行可能なものに変えるが、ソースがプログラマが編集して保存する主要な表現である。
プロジェクショナルな編集システムを使うことで、プログラムのコアとなる表現はそれを使う特殊なツールのフォーマットで行われる。
プログラムを編集したいとき、ツールの編集環境を立ち上げる。
これらの表現はテキストかもしれないし、あるいは図、テーブル、書式であるかもしれない。
Microsoft Accessのようなデスクトップのデータベースツールは、プロジェクショナルな編集システムのよい例である。
編集は言うまでもなく、全部のアクセスプログラムのテキストのソースコードを決してみない。
その代わりに、アクセスを立ち上げてデータベーススキーマ、レポートクエリなどを吟味するさまざまなツールを使う。
プロジェクショナルな編集がソースベースのアプローチよりも多くの利点を与える。
一つは異なった表現を通して編集可能だということ。
状態図が図表の形式でしばしばもっともよく考えれるが、プロジェクショナルなエディタで状態図を図形としてレンダリングでき、その形式で直接編集することができる。
ソースでは、テキストを編集できるだけであり、テキストを図として見るのにヴィジュアライザを通して見ることは出来るけれども、図を直接編集することはできない。
このようなプロジェクションが正しい情報の入力をと正しくない情報の拒否をより容易にするのをコントロールできるようにする。
テキストのプロジェクションは、オブジェクトのメソッドコールを与えられることで、正当なクラスのメソッドを示すだけであり、また正しいメソッド名の入力を可能にするだけである。
これはエディタとプログラムに、よりタイトなフィードバックサイクルを与え、そしてエディタがプログラマにより多くの補助を提供するのを可能にする。
同時にあるいは選択的に多くのプロジェクションを持つこともできる。
Intentional Software社の言語ワークベンチのデモンストレーションがC言語ライクの構文で条件の表現を示す。
メニューコマンドで、Lispライクの構文にスイッチでき、あるいはタブ形式で見せることもできる。
これは手元にある特定のタスクの情報を見たい、あるいは個々のプログラマの好みに合わせたい、ベストな方法をどちらのプロジェクションでも使うことを可能にする。
しばしば、同じ情報の複数のプロジェクション、たとえばフォームのフィールドとしてクラスのスーパークラスあるいは編集環境の別のパネルにクラス階層を見たいことがある。
これらの表現は基礎となるモデルのプロジェクションであって、そしてそれでそのモデルのセマンティックの変換を促進する。
メソッドのリネームをしたい場合は、テキスト表現というより、むしろモデルに関して補足されることができる。
これはテキストというよりセマンティックモデル上のオペレーションとしてのセマンティックに対する多くの変更を可能にする。
これは安全で効率的な方法でリファクタリングすることに対して特に助けとなる。
プロジェクショナル編集はほとんど新しくなく、ファウラーがプログラミングを始めたことからある。
それは多くの利点を持っているが、それでもなおもっとも本格的なプログラミングはまだソースベースである。
テキストは、その多くの欠陥があるにもかかわらず、共通のフォーマットであり、それでテキストを操作するツールは広く使われることができる。
これが大きな相違を作ったとてもよい例が、ソースコードマネジメントである。
これまでの数年にわたってソースコードマネジメントに非常に多くの面白い展開があった。
同時編集、diffの表示、自動マージ、トランザクショナルなリポジトリ更新、そして分散バージョン管理といったものである。
これらすべてのツールは、それらがテキストファイルだけを操作するので、プログラミング環境の広範囲で効果を発揮する。
結果として、本当にインテリジェントなリポジトリ、diff、マージが可能な多くのツールがそれをできない残念な状況を見ている。
この問題はより大きいソフトウェアプロジェクトでとても重要な問題であり、大きなソフトウェアシステムがいまだソースベースの編集を使う傾向にある理由の一つである。
ソースはほかに実用的な利点がある。
いくつかの変換はテキスト処理ツールでとてもよく自動化できるが、それはプロジェクショナルシステムが必要な変換を提供しないなら非常に有用である。
そして、正当な入力のみを許可するプロジェクショナルシステムの能力が有用である一方、ソリューションを通して考えると、一時的なステップとして、何かをタイプすることはしばしば有用である。
モダンなIDEの偉業の一つは、ケーキをもってそれを食べる方法を提供することである。(はぁ?)
しかしながら、ソースをIDEにロードするとき、編集をより容易にするすべてのプロジェクショナルなテクニックを使うことを可能にするセマンティックモデルを作成する。モデル補助ソース編集とファウラーが呼ぶアプローチ。
これをするのは多くのリソースが必要となる。
ツールはすべてのソースを解析しなければならず、セマンティックモデルを保持する大量のメモリ領域を必要とするが、双方の世界にとってベストに近い結果を得る。
ソースとプロジェクショナルな編集の流れについて考えたとき見つけた役に立つコンセプトの一つは、ロール表現の概念である。
ソースコードは二つのロールを演じる。
編集表現(我々が編集するプログラムの表現)と保存表現(我々が永続的な形式で保存する表現)である。
コンパイラがこの表現を実行可能なものに変換する。
インタプリタ言語のソースはとてもよい実行可能な表現である。
コンパイル中のようなある時点で、抽象的な表現が生成される。
これはプログラムを処理しやすくする、純粋にコンピュータ指向の構築である。
モダンなIDEは編集を補助するために抽象的な表現を生成する。
モダンなコンパイラが、シンタックスツリーやコールグラフといった、異なる目的のためにしばしば複数の抽象的な表現を生成する。
プロジェクショナルな編集で、これらの表現は異なってアレンジされる。
コアの表現はツールによって使用されるセマンティックモデルである。
この表現は複数の編集表現に映し出される。
モデルは別個の保存表現を使って保存される。
保存表現はあるレベルの人間に読めるもの、たとえば、XMLにシリアライズされるといった形になるだろうが、それは正気の人間が編集のために使うであろう表現ではない。
この章全体的に何か締まらない感が。