[b-free 608] Re: 仮身名

Hideaki Suzuki (h1suzuki@Bridgew.edu)
Wed, 24 Sep 97 13:50:28 -0500

どうも、林さん、こんにちわ。

In "[b-free 606] 仮身名" with Takanori Hayashi ,
(07:44:14 PM +0900 in September 24,1997)
- takanori wrote.

| 林です。Subjectを変えました。
|# [Subject: 仮身名]

了解。

|
|In message <199709240821.RAA04055@b-free.orient.co.jp>
| "[b-free 602] Re: "
| "h1suzuki@bridgew.edu (Hideaki Suzuki)" wrote:
|h1suzuki>  「Alias 型の Filesystem がなぜ長い名前を必要としているのか(た
だの時代遅れ
|h1suzuki> の短い名前への Patch みたいな物か)? そして、なぜ(流行という以
上に)B-fr
|h1suzuki> ee でそれを採用しようとしているのか?」もうちょっと、つっこんだ意
見の交換が
|h1suzuki> 欲しいのです。
|
| 8.3(FAT)や13(old UNIX)では識別子として短すぎるのが主な理由でしょう。
|Javaのライブラリメソッドのフルネームとか考えるとBTRON1の20文字もいま
|いちですね。

僕もそう思います。>短すぎの識別子。
でも同時に、ファイル名に内容識別の全てを頼ってるために、ファイル名が長くなり
がちなのも一因とは思えませんか? ファイルに付随する情報と言えば「ファイル名
と保護属性のみ」というシステムですから。例えば、拡張子はその良い例だと思うし

20文字は、短すぎます。それには、異議はないのですがねぇ。
でも、まえに林さんがいったような「1Kもとれば」とかいうのは、「それって実身
名に何でもやらせ過ぎるからじゃないの?」って感じがしてなりません。500文字
って事は、25文字*20行ですよ! そんなのをファイル名として受け付けるのは
どうかな。情報の置き場所としてファイル名以外の適当なところがありそう!

# まあ、20文字が短すぎると言った段階で、互換性は捨てているかもな。

# 林さんが「TAD部 を実身名以外のファイル属性にしよう」というのは同意という
より好感が持てます。
# でも、それも、実身に付随する情報なのか? という疑問は残りますが。
# 実身に付随する TAD の情報って、単なる「TAD 主レコード」じゃないの?

# 要するに、仮身に、実身名以外の、仮身に付随する情報が表示できたら、嬉しい
のだ。
# 「もっと自由な続柄」見たいのね。すなわち、仮身名。

Java は、あれは Alphabet でファイル名をきめてますからねえ。そりゃあ、ファイ
ル名も長くなります。
そうだねえ。でも、そのことを考慮しても、50文字もあれば足りるんじゃない?
統計を取ってないから、全然判らないけど。

|h1suzuki> ◆仮身名と実身名の本質もしくは応用上の違い
|h1suzuki>
|h1suzuki> 実身名:各ファイルの「内容」を識別する名前である。
|
| 識別子が20文字で足りるとは言えません。Javaの例では識別子はやはり
|フルネームでしょう。メソッドごとに実身を分けてマニュアルを書くと
|して他に良い名前の付け方はありますか?

例えば、Method の Line-comment のような部分は、仮身名の候補ですね。
クラスの名前については、例えば、BC++ だと32文字の識別子の長さ制限があった
気がしますが。Java ではそう言った物はないのだろうか。Compiling を高速にする
ために Hash とか使っている限りは識別子の長さ制限はありそうだけど。それにして
も、32文字の識別子って結構長いですよ。32文字を越えたいと思ったことありま
すか? とくにクラスの場合はしょっちゅう繰り返す文字列になるから、適当に短い
方が誤植とかなくて良いのだ。まあ、BTRON なら仮身を貼り込むだけで良いのだろう
けど。
そう言えば、引数の情報は、仮身名にすべきでしょうか? 実身名にすべきでしょう
か?
ここでは、引数の宣言自体は実身の中にあるとして、見出し的に仮身に表示するよう
な引数情報のことを言っています。
引数の情報も実身名の中に入れてしまうと言うなら、32文字じゃあはなはだ足りな
いでしょうね。でも、実身名は識別子だけにして、仮身名の方で引数の情報を表示す
るなら、やっぱり32文字で十分。

要は、引数形式を(ファイル内にもつ以外に)常に実身名として表示する必要がある
か、時には Method の名前で十分な場合があるから、仮身(引用方法)に依存して引
数形式を追加情報的に扱うか、という違いですね。まあ、Overload とかありますか
ら、その辺は意見の分かれるところかな。
何でも実身名に詰め込んでいく方向性か、どんどん実身名を単純化(単一化)してい
く方向性か。

|h1suzuki> 仮身名:各ファイルへの参照を提供する「仮身」に、表示される名前であ
る。
|h1suzuki>
|h1suzuki>  現在、<仮身の表示属性+文字列>で、何とか仮身名らしきことを達
成しうるが
|h1suzuki>  それは、必ず文字列が共に使えなければいけなく、smart ではない。
|h1suzuki>  例えば、「キャビネット」上では不可能である。
|
| キャビネットで足りなければ図形実身を使うとか、名前を付けられる
|キャビネット様のアプリケーションを使うという手もありますよ。
| 仮身名を否定するものではないけど、要求の内容だととりあえずは
|運用かアプリケーションで解決がついてしまいそうですね。

えっと、仮身名をサポートするというのは、それこそ、「どこでも出来る」という事
を意味します。例えば、表計算の中やマイクロカードの仮身フィールドでもです。
これって、「基本の部分としてサポートする v.s. 追加品として対応する」の違い
ですね。
新しい App がでる度に「そうできる物と、出来ない物がある」というのでは、あま
りに、仮身というせっかくの普遍的データが、もったいない。^^;;

その辺って、Enableware や BTRON の実身仮身が「後から付け加えた物ではないから
、どんな App とも連携機能する」とかそう言ったことと、同じ議論じゃなかったっ
け?

|h1suzuki> で、僕は、「仮身名は別の種類の Record として実装すれば、仮身セグ
メント・リン
|h1suzuki> クレコード・仮身名レコード、と3っつに名って管理は大変だけど、実装
も互換性も
|h1suzuki> 問題ない」と書きました。ファイルシステムの使い方がどう変わるかは
、僕には分か
|h1suzuki> りません。むしろ、実身名を長くすることの方が、変化を生むと思う。
|h1suzuki>
|h1suzuki> 利点1
|h1suzuki>  互換性の問題。仮身名は、互換性の問題に対処しつつ、仮身に表示さ
れる文字を
|h1suzuki>  増やすことが出来る。
|
| 少なくとも「仮身セグメント・リンクレコード・仮身名レコード」のセット
|では互換性は確保できません。非対応システム上で仮身の追加と削除が行わ
|れた場合に何が起きるか考えてみて下さい。

なんと!
こんなところで、例の対応の弱さが出るとは。;_;
確かに、「セグメントとレコードの対応」は、確か、<並べた順>でしたね。
そんなのって、最低だけど。

| 互換性は諦めてリンクレコードを拡張するのが一番スマートでしょう。
|# この場合、互換ファイルシステム上への複製では仮身名はすべて削除します。
| 仮身セグメントの拡張とか仮身セグメントに続くセグメントとかの方法も
|考えられるけど、どちらも互換性はないです。

そうですね。僕も、この方法が一番スマートに感じます。
それに、仮身セグメントよりレコードの方が、App とか移植する際の労力が少なそう

|h1suzuki> 利点2
|h1suzuki>  長い名前は、それぞれの使われ方に依存する情報を含む可能性が高い

|h1suzuki>  そういった物は、仮身側の情報とすべきで、実身名は中立に保つ方が
いい。
|h1suzuki>  特に、今後 B-free がネットワークに繋がった場合、実身名はどう云
った
|h1suzuki>  引用のされ方も許容できる中立的な名前を取るべきであろう。
|h1suzuki>  なぜなら、実身名は、常に整合性のとれた同じ名前で表示されるから

|
| 先に書いたように前提に問題があります。中立的な識別子は短くなるどころ
|か色々な要素を取り込んで非常に長くなる可能性があります。そのような場合
|無理に短縮すればそれこそ一面的な見方になるでしょう。
| 仮身名を否定する気はありませんが、少なくとも長い実身名への要求を代替
|できるものではないと思います。

これは、今一つピンとこないなあ。
中立にするために「ながーくする」ってどう言うこと?
普通、長くなればなるほど Specific になって、うーん。使われ方に密着した情報に
なる気がするんだけど。すなわち、仮身よりになるって事。

例があったら出してください。

|h1suzuki>  例えば、「JDK 1.1.1」という実身名が「JDK 1.1.2」に変わったとこ
ろで、
|h1suzuki>  ネットワーク上では、名前の修正は不要にしたい。でも、実身名を長
くし、
|h1suzuki>  使われ方に依存した情報を名前に使えば、そうは行かないかも知れな
い。
|
| そのような実身名変更は間違っています。「JDK 1.1.1」と「JDK 1.1.2」は
|別の物でしょう?

えっと、では、JDK 1.1.1 を、その各種ファイルが入ったキャビネットと考えてみて
ください。
キャビネットの中身を入れ替えて、JDK 1.1.2 にしてみました。というのは?

リンクする側では、何も変更せずに、最新の Version にリンクしていることが保た
れますね。で、このキャビネットの中に、JDK 1.1.1 へのリンクがあることは、ぜー
んぜん Okey です。この新しい JDK1.1.1 キャビネットには、古い JDK 1.1.1(いま
JDK1.1.2 )のファイルがリンクされているのですけど。

|h1suzuki>  Host で「中国建国、秦」という名前で使っている実身は、秦の資料の
|h1suzuki>  ために link を貼りたい「王朝の滅亡の歴史」という Client の
|h1suzuki>  実身仮身ネットワークの中には、表示するには不適当な名前かも知れ
ない。
|
| どういう状況か良くつかめませんが、「中国建国、秦」をどういう名前に
|したら適当なのですか?

例が良くなかったかな。
ついつい、最近の身の回りの題材を使ってしまうから。
# 最近、中国の歴史のクラスがある。^^;;

えっと、「王朝の滅亡の歴史」という実身の中なら、秦のことを参照するのに「秦の
繁栄と衰退」とかそういった名前の方が「中国建国、秦」より、Context にあってる
と思いませんか? でも、「秦王朝の経済状況」とかそう言った実身の中では、「秦
の通貨事情」とかいうほうが参照する名前としては適切に思う。でも、みーんな、「
秦の資料」という意味で同じ実身を参照する。

# 「秦の資料」をさらにネットワーク化するという話もあるが、それは又別のこと

# 他に、引用するのなら「どこからの引用なのか」などは、仮身名の範疇だろう。

|h1suzuki> 利点3
|h1suzuki>  実身名が、短いため、もしくは外からの link を考慮して、より抽象
化され、
|h1suzuki>  実身の内容そのものを表すようになる事を促された結果、実身名によ
る検索
|h1suzuki>  が、より、Hit する可能性が高くなる。正規表現を入れることも重要
だが、
|h1suzuki>  普通に単純検索して、検索成功することも、重要。
|
| 短くすると逆にヒットしすぎて意味が無くなるかも。検索結果一万件に
|なっても意味ありますか?

これはおかしいと思う。
ヒットは出来るだけした方がいい。
で、後は絞り込めばいい。
Inforseek とか見て、そう思いません?

|
|以上、要点は
|1. 中立的な識別子が短いとは限らない → 長い実身名には要求がある
|2. 仮身名は互換性が確保できない
|
|
|---
| 林(takanori@ohsaki.meidensha.co.jp)

以上、2は同意します。
互換性の利点はあまりありませんね。
1はまだ理解に至っていません。
長い名前が「なぜ実身に付属する情報でなければならないのか」とか。

--------------------------------------------------------------
Hideaki Suzuki (SO in Bridgewater State College)
e-mail H1Suzuki@Bridgew.edu
Home Page http://www.yashi.com/h1suzuki (Under Constr.)
Nifty-Serve KGH06253