In message <371FE23633A.D92F.anakamur / exa.i-tech.co.jp>
anakamur / exa.i-tech.co.jp writes:

> つまり、両者は従属関係である、ということをはっきりさせたいなー
> などと思ったのでふ。
> 手続きに限ればそもそも「失せる」と「止まる」を区別する事自体
> 無意味なんで、一般的にそれらに区別が有る事を忘れちゃってるかなと。

そもそも手続きが「存在する」という概念からして不明だったり (^^; なんて
いうか，「溝があります．これは単に溝です．水がながれて来ました．水がな
がれている状態を『川』といっておきましょう．水が全て流れきってしまいま
した．でも已然として溝はあります．」っていう感じ．

# 溝 == 静的なプログラム構造，水 == スレッド．ただしここでは本来の
# thread of control であり特に ruby の Thread オブジェクトを意味しない．
# このたとえだと関数定義を説明できないんだけど，まあいいや．


Ruby 的な Thread オブジェクトのインスタンスについては間違いなく存在す
る/しない，動いている/止まっているが定義できますが，「失せる時には止
まっていなければならない」と「止まったら失せなければならない」では全然
意味が違いますしね．

どうせ Thread は特殊なオブジェクトなのだから，「オブジェクトは疑似変数
self により自己の参照を保持している」っていうのと「いかなる Thread オ
ブジェクトにも参照されていないオブジェクトは GC の対象になる」っていう
のとをモデルに加えてやると，現在の挙動は矛盾なく説明できる，かな?


> いや、言いたかったのは「オブジェクトは」外部から干渉できるぞ、って
> だけの当たり前のことです。
> オブジェクトの個々のメソッドは(手続きなので)出来ないのは無論です。
> 
> 手続きは「存在するイコール走ってる」ですが…よって存在「中」に
> 外界からいじることが出来ないのですが、
> オブジェクトは当然「存在してるからって走ってるとは限らない」ので
> 走らせる(振る舞い(?)させる)かどうかの選択肢が(外界に？)あります。

そんな事いったら一所懸命「プロセス間通信」とか「並行システムの意味論」
とかを研究している人がかわいそうです．そこまで考えなくても普通のサーバ
は「外界からの要求を受け取って作業を行い返事を返」しますし．


> だって、俺のwwwサイトにも書いたけど、手続き型(笑)サーバプログラムを
> 「設定を変えるために」停止させないとならん、そのためには
> それが「使われていない」休日でないとならん(よって休日出勤(笑))
> ってのも、何か間違えてると思いません？

それは，「サーバの設計が間違えている」のです．とか (^^;

# inetd.conf かきかえて kill -HUP とか．


> こーゆーのも、オブジェクト化しちまえば、その「ある側面」が
> 活きることによって、俺が(笑)楽になるんでねーかなーと。

サーバプログラムは常にオブジェクトとみなす事ができます．メッセージを受
け取って，返事を返す．内部の状態は隠蔽されている．オブジェクト以外の何
者でもない (^^;


> > # 実は上のだと「Object-Based」であって「Object-Oriented」ではない，と
> > # する人もいますが（っていうか既に定説ですが），わたしはその立場を取ら
> > # ないので (^^;
> 
> 型に対して深く考える(笑)のが必須なんでしたっけ？＞Oriented

「早わかりオブジェクト指向」なんていう OOPSLA '88 だかなんだかでの講演
の翻訳あたりでも出ていますが，要するに「継承がないと Object-Orientd と
はいわない」っていう「定義」です．

いかにも「分類する必要があるんで名前を分けた」っていうだけの感じなので，
あんまり気にしない事にしています．だって全然本質的じゃないじゃない....


> アリオッチってなんでしたっけ…どっかで聞いた記憶が…

「剣の騎士」です．

# と，ちょっと外してみる．

-- 
柳川和久 @ 東大阪市 . 大阪府                                 April 24, 1999
「こんな事もあろうかと，少し前に宿屋でパクっておいたのよ!」
「....こ，こんなことって，あのなあ....」