OSASK-HB​/0002

kcpshについて

• (by K, 2008.09.30)

(0)

• 結局、9月中のリリースも出来ませんでした・・・どうもすみません。
• ただ何もしていなかったというわけではなくて、以下のような妄想を膨らませていたらそちらに気を取られてしまいました。罪滅ぼし（？）に、ちょっと紹介しようと思います（書いたら考えがさらに整理されるかもしれないし）。

(1)

• 最初の出発点は、「ぐいぐい01」の終了APIの設計でした。一般のOSではアプリ終了時にリターンコードとして整数値を返せます。0なら正常終了で、それ以外ならエラーだというのが一般的な慣習です。たしかDOSでは8bitの値しか返せませんが、最近のOSでは32bitのintを返せるような気がします（違ったらすみません、仮に違っていても本論とは無関係なので指摘には及びません）。
• 8bitからいつの間にか32bitへ拡張進化したのであれば、将来はもっとビット数が増えるかもしれないと僕は勝手に思いました。それで「ぐいぐい01」では、ビット数を規定せず、アプリが任意の長さのintを返せるように設計してやろうと思いました。
• しかし考えてみると、なにもintにこだわらなければいけない理由はありません。floatやdoubleを返したい場合や、文字列を返したい場合だってあるんじゃないかと思いました。ということで、そういうことができるような拡張余地のあるAPIに設計しました。

(2)

• そうなると今度はシェルが気になりました。ここではコマンドラインシェルを想定しています。せっかくint以外を返しても、それを反映できません。intかdoubleか文字列かくらいならまあ表示すればいいかもしれませんが、文字列なら文字列でエンコードが何かという問題がありますし、それに何らかの構造体を返すかもしれません（たとえば複素数）。そんな場合、扱いに困ります。ということで、とりあえず、適当環境変数に代入できればいいかなと考えました。任意のバイト列であってもたとえばBASE64でエンコードすれば、環境変数に代入することはできると思ったわけです。代入できてしまえば、比較したり表示したり、別のアプリの引数に指定したりと、あとからどうにでもできると思ったわけです。
• こういう設計にすると、シェルはアプリから返される構造体について、どれがどの構造体であるかくらいは知っておいたほうがいいと考えました。でも構造体の中身のフォーマットまでは知らなくてもいいです。イメージとしては、構造体名（もしくはそれに代わるIDのようなものでも可）を環境変数へエンコードする場合に先頭につける感じです。

(3)

• しかしここから僕の妄想はやや暴走します。このままでは単なる構造化思想どまりだけど、メンバ関数的なアプリなどを設定ファイルにわんさと書き並べることで、これをオブジェクト指向シェルに出来ないものかと思ったわけです。確かにこれはなんだかかっこよさそうです。ただそれだけの理由で、この構造体というかオブジェクトにこのメッセージを送ったときは、このようなコマンドラインを入力したのと同等と見なす、みたいな設定ファイルを書けるようにしようと思いました。そんな機能が果たして必要なのかどうか全然検討することもなく、単にこれくらいの機能であればつけちゃっても大して大変そうじゃないな、と思っただけという超安易な理由です。
• たとえば、画像ファイルを見たいと思ったら、 Susie(File("FUJI.JPG")); とか入力するわけです（文法はC++っぽくしてみました・・・もっともまだ妄想ですが）。File()は、Fileオブジェクトを生成する関数です（デフォルトコンストラクタ）。文字列はそのままではファイル型ではないので、こうしています。というかオブジェクト指向なので、 File("FUJI.JPG").view(); とかすればそれだけで適当なビューアで表示されると思います。
• なおこのオブジェクトは、ビューアの終了後に自動で破棄されます。というのは、名前が付いていないからです。破棄されるのが嫌なら名前を付けます。 File fuji("FUJI.JPG"); fuji.view(); みたいに。これだと delete fuji; ってするまでメモリに残ります（C++と若干異なり、ポインタ型じゃなくてもdeleteできるということにする）。

(4)

• こういうことを妄想していると、そもそもこれは環境変数じゃなくてファイルそのもののほうが適切なんじゃないかと思えてきます。拡張子がクラスのIDを表しているとすれば、結構自然です。これをどうするかは今も考え中ですが、この考えも取り入れるかもしれません。ただ環境変数という考え方も好きなので、最初に環境変数内に同名のオブジェクトを探し、なければカレントパスから探す、みたいな設計にするかもしれません。こうするのは、既存のファイルフォーマットと僕の考えている構造体というかオブジェクトの内部構造が結構かけ離れている感じがするせいです。この辺は未定です。
• ファイル名がそのままオブジェクト名として使えるのであれば、 FUJI.view(); で画像は見れます。この場合、カレントディレクトリ内にFUJI.TXTがあったりしてはいけません。その場合はどちらを指定されているのかシェルは判断できないので FILE("FUJI.JPG").view(); の方法しか使えないことになります。

(5)

• このシェルにバッチファイルの処理のためにifやwhileなどの制御命令の処理を適当に追加すると、バッチファイルの文法がまるでC++みたいになります。なんだかニンマリしてしまいます（笑）。
• このページの表題の「kcpsh」というのはそのシェルのとりあえずの名前です。
• まだいろいろと妄想中ですが、まとまってきたらまた書きます。

(6) 2009.07.29続編

• またしてもこのアイデアに帰って来てしまいました。きっかけはこうです。UNIX的なものが好きな人たちは、さまざまな問題をコマンドの組み合わせで解決しようとする傾向がかなり強いです。それはそれでいいことなのですが、しかし、「そんなの○○関数を使えば一発なのに」なんていう場合でも、コマンドを組み合わせてどうにかしたがります。
• これはどういうことなのかというと、結局アプリを作るのが面倒だからだと思うんです。そしてアプリを作るのが一番ラクなのは何かといえば、それはインタープリタによる対話型の一行実行でしょう。・・・ようするに、シェルの文法をC++と同じにすればいいだけです。
• ということを思ったので、とりあえずメモ。

こめんと欄