コマンド群も一様平板なものと考える必要はありません。これまでの コマンド言語では命令語に目的語を必要に応じて与え、オプションを 付加するというものが一般的でした。この場合、それぞれの命令語は 綴りの上で他と区別できなくてはならず、非常に多数になると覚える ことも難しくなります。例えばUNIXのシェルコマンドなどはこれです。
よりアプリケーションに近くなると、有限状態機械を考え、ある 状態にあるときはその状態の中でだけ有効なコマンドを考えることで 出来るだけ自然言語に近い、少ない数の動詞を覚えればすむように 設計できます。例えばCERNLIBのKUMACなどです。
KONOEではさらに操作対称をオブジェクトと認識できる訳ですから、 より進んだコマンド言語の実装が可能なはずです。KONOEの操作の 上で目に見える概念はオブジェクトとして定義されているはずです。 そのメソッドに対応したコマンドを用意することで、構造的にも 整理されたコマンド体系を実現できると思われます。例えばコマンド 定義を行なうラッパークラスを考えることで命令定義が非常に 簡単になります。
既存のスクリプトと互換性を持たせるかどうかは議論のあるところです。
コマンド言語が対象とするもの=オブジェクトはアプリケーションの中でも オブジェクトとして位置づけられているものです。ただし、アプリケーション とは単一のプログラムをさすのではなく、ネットワークに分散したプロセス 全体で一つのアプリケーションと考えることが出来ます。もちろんコマンド 言語の直接の対話先は(なんらかのプログラムを通して)コントロール センターになります。この意味で、コントロールセンターの知っている オブジェクトやそこから検索できるオブジェクトが処理の対象となります。
オブジェクトにはそれぞれ名前がついていると考えます。その名前を使って オブジェクトを指定し、そのメソッドをコマンドとして呼び出すことに なります。そしてメソッドの戻り値も文字列としてコマンド言語処理系で 利用できなければなりません。また、個別のオブジェクトだけでなく、 クラス自身も名前を付けて呼び出されなければなりません。例えば静的な メンバーの呼び出しなどに必要です。
パラメータネームスペースはコマンド言語の中でも正しく扱われる必要が あります。ネームスペースクラスに問い合わせるという方法でも実装でき ますが、例えばシェルでの環境変数の参照のような簡単なシンタックスを 考えることも出来ます。
KONOEでは、以上の関係から、オブジェクトの名前とメソッド、引数で コマンドが規定されることになります。コマンド言語という性格から 省略が可能であることが期待されます。例えば現在のオブジェクトという 概念があればそれを.であらわすなど。また、現在のオブジェクトは 最後に宣言されたものとするなど。また、オブジェクトが何か別の オブジェクトを参照しているとき、そのオブジェクトを指定する方法も 必要です。