[b-free 614] Re: 仮身名

Takanori Hayashi (takanori@ohsaki.meidensha.co.jp)
Thu, 25 Sep 1997 18:37:41 +0900

林です。

In message <199709250705.QAA07838@b-free.orient.co.jp>
"[b-free 612] Re: 仮身名"
"h1suzuki@bridgew.edu (Hideaki Suzuki)" wrote:
h1suzuki> 内容を識別とは、例えば、「JFK の暗殺」の事についてかかれた実身に「JFK の暗殺
h1suzuki> 」という名前を付けるとか、明治の開国のごたごたを集めた実身に「明治維新」とい
h1suzuki> う名前を付けるとか、そう言ったことです。

そういう目的指向で作成された実身だと短い名前になるかな。
しかし一方で、短い名前を付けることが不可能ではないにしても
困難な場合もあると理解してください。

h1suzuki> あと、えっと、「いつでも」に対しては、
h1suzuki> 情報はある種の集まりがあって、ファイルを成すのですよね。その「ある種」という
h1suzuki> のが実身名になるのでは? それは、Context-free な情報で、そのファイルが構成
h1suzuki> される理由みたいな物です。

ファイルが「ある種の集まり」である限りはそうかもしれない。
でもそういう場合ばかりではない。例えばその集まりの「断片」
である場合、実身名は「集まりの名前+集まり内での断片の位置」
のような形になって長くなるでしょう。
そういう場合でも発想を転換すれば短い名前を付けられるかも
しれない。しかし、それを要求するシステムは使いたくないよ。

h1suzuki> TAD も文字は基本的に固定長じゃん。可変長は Escape-code による扱いになる。ま
h1suzuki> あ、RISC な思想は持っていないけど、今まで固定長だった物を可変長にするのは、
h1suzuki> 一種抵抗みたいな物があります。

個別のセグメントは別として全体としては可変長、というより
不定長でしょう。個人的には、固定長を使ってチマチマ高速化を
図るより、全データを可変長レコード列にして可変長レコードの
全体を高速に扱う工夫をする方がやり方としては好きだけど。

h1suzuki> # Win とかのファイルシステムって、どこに、あの8文字以上の情報をしまってる
h1suzuki> の?

本論には関係ないけど。VFATの場合ですが、複数のディレクトリ
エントリを使って長いファイル名を入れます。通常のエントリの
後に長い名前の入る拡張エントリが続きます。ちなみに非対応の
システムからは拡張エントリはボリュームラベルに見えます。
ついでに言うと8.3形式の方には短いファイル名が入ります。

h1suzuki> 言い換えると、「仮身内で改行なしに一般的な用紙幅をこえたりしない長さ」と言う
h1suzuki> ことかな。

そんなのは文字の大きさや用紙幅で変わるでしょう。文字サイズ
を半分にすれば倍入るのだから。

h1suzuki> すると、実身名を長くしたいというのなら、この、注釈レコードを使用するかも知れ
h1suzuki> ないと言う理解で良いですね? 仮身にこの情報を表示しようと言うのですか? そ
h1suzuki> れは、まだ賛成できないけど。

開いた仮身には実身の中身を表示するのだし、実身名だって
ピクトグラムだって実身に書き込まれた情報だし、そういうのと
特に違いはないですよ。

h1suzuki> | たとえば図形実身のプレビュー画像をアイコンみたいに表示するとして
h1suzuki> |これを仮身に入れるの? こういうのはやはり実身に付属する情報だよ。
h1suzuki>
h1suzuki> ???
h1suzuki> 「開いた仮身」じゃだめなの?
h1suzuki> どうせ、表示領域は、標準の App が書くんだし。

「開いた仮身では注釈レコードを表示するのが原則」とかなって
しまえばそれでも良いのだけど。主TADレコードをそのまま表示
するだけの現状では意味ないですね。
ついでに、開いた仮身の表示をデフォルトアプリケーションが
するのもなんとかして欲しいですね。柔軟性欠如も甚だしい。

h1suzuki> | Javaのフルスペルは「パッケージ名.クラス名.メソッド名」の形式
h1suzuki> |だったと思うけど、50文字で足りる?
h1suzuki> | この話は、階層化されたコンテキストの中でのクラス名なりメソッド
h1suzuki> |名を実身名にするのではなくて、「コンテキストに依らない識別子」
h1suzuki> |としての実身名が要求される場合だからね。
h1suzuki>
h1suzuki> この点については、僕の、「b-free 609 自己FOLLOW」を参照してください。と言う
h1suzuki> ほど、詳しく書いてませんが。
h1suzuki> Java などの「旧式ファイルシステム」の上の名前の一過性に頼った言語は名前の結
h1suzuki> 合を使わないと、Overload などで上手くありません。ですから、実身名自身が Met
h1suzuki> hod 名を Full spelling する事は無いと思います。

例はばっさり切りますが、私はJavaを半端に実身/仮身化した
言語に興味はありません。先例はJavaのライブラリマニュアル
を実身/仮身で表すのにメソッド単位で実身を作る際の実身名の
付け方としてあげたものです。実身/仮身でなくても良いから
HTMLマニュアルで考えてみましょう。個別のメソッドの説明の
タイトルは何にします? 私なら長くてもフルスペルを使います。
長い名前はシステムが識別するために必要なのではないのです。
人間が適切に識別するためにこそ必要なのですよ。
また、この「Javaマニュアル」の例は、自身が「情報の断片」
である場合の典型です。「Javaマニュアル」は短いけど「Java
マニュアルの中のXXというクラスのYYというメソッドの説明」
はとても長いです。

h1suzuki> そうですね。「Keyword v.s. Identifier」はすごく良い描写だと思います。
h1suzuki> 僕の見方では、Identifier は十分に簡潔になれるという立場にいるわけで、その辺
h1suzuki> の状況理解(認識?)がもう少し必要みたいです。

上記「Javaマニュアル」が反例です。他にも同じような状況
は一杯あると思いますよ。

h1suzuki> で、技術的な制限の少ない方を取るのは無難なんですが、僕はそこで、B-free に P
h1suzuki> olicy を求めていた(いる)わけです。あまりに自由度が大きいのは、時に混乱を招く
h1suzuki> というのは周知の事実。まあ、両方試してみてから、Policy を選ぶという方法が B
h1suzuki> etter かなぁ。

そこで制限してしまうのはpolicyというよりideologyでしょう。
枠は大きく取って使い方はユーザに任せるのが技術者のpolicy
というものです。

h1suzuki> | そうだよ。でも「どこでも」というなら非対応システムに
h1suzuki> |持っていっておかしくなるようなものでは困るでしょう。
h1suzuki> | 下位互換がいらないなら「仮身名」は良い機能でしょう。
h1suzuki>
h1suzuki> 仮身名を普遍的に使うという立場をとるなら、やはり、System の仮身名として sup
h1suzuki> port するべきですよね。App の運用で誤魔化すべきではない。でも、
h1suzuki>   「下位互換がいらないなら「仮身名」は良い機能でしょう。」
h1suzuki> って、どういうこと?

下位互換性(1Bにデータを持っていくこと)を考えなくて良いなら、
仮身名(リンクレコード拡張による)は良い機能だから、B-Freeで
実装するのに反対しない、ということ。
でも、下位互換性の必要な場面では使えないし、長い実身名を不要
にするようなものでもないので誤解しないで欲しい。

h1suzuki> これは、まず、Java をあのまま実身仮身ネットワークに持ってきた場合の話ですよ
h1suzuki> ね。それは「おかしな移植法だ」と言うことは述べたとおりです。実身仮身ネットワ
h1suzuki> ークにするなら識別子への結合が必要になると思うし、そうしないのなら今までと同
h1suzuki> じ扱いのファイルで、Java を組むことになるでしょう。変に実身仮身にしない方が
h1suzuki> いいと云うことです。

上に書いたように、Javaではなくて「Javaマニュアル」の例。
別にJavaに囚われなくてもマニュアルには同じような例が一杯
みつかると思うよ。

h1suzuki> | 普通は実身を(浅く)複製して変更しますね。
h1suzuki>
h1suzuki> 浅いというのは、木構造ではないので、よくハッキリしませんが。

目的の実身から参照される実身群全てを複製するのが「深い」
複製、目的の実身内の仮身は複写するのが「浅い」複製。

h1suzuki> | そういうのは「最新パッケージ」というキャビネットに
h1suzuki> |「JDK 1.1.1」を入れておいて入替えるか、続柄で「最新」
h1suzuki> |を付けておくかするのが、正しい処方かと。
h1suzuki> | 直接リンクの中身を下手に変えると、互換性が取れなくて
h1suzuki> |動かないものが出るかもよ。
h1suzuki>
h1suzuki> 「動かないもの」とは?
h1suzuki> もすこし、具体的に云ってくれると、想像できるかも。

コンパイラの特定のバージョンに密着したコードを書いていると
バージョンアップしたときに動かないことは良くある話です。

h1suzuki> 続柄は、ネットワークを越えては使えないのは、承知のことと思います。何せ、シス
h1suzuki> テムに固有の table&index で文字列を表示してますものね。だから、最新という続
h1suzuki> 柄を付けるのは、仮身を持っている Client の仕事になりますね。これは機能しない
h1suzuki> と思います。

使えないとは言えないよ。ネットワークに乗せるときには文字列
にして送るとかの技は使えるから。

h1suzuki> 「最新パッケージ」は、僕の JDK1.1.1 という名前を置き換えただけで、とくに同じ
h1suzuki> Analogy に聞こえますけど。

最新版を使いたければ「最新パッケージ」につなぐ。特定の
バージョンに依存する場合はそのバージョンにつなぐ。これで
バージョンアップ時にはどちらもそのままにできます。

h1suzuki> うーん。全文検索まで行かなくとも、貼ってあるリンクで絞り込むとか。例えば、
h1suzuki> 「私撰集 で 小野小町を含む物」とか。
h1suzuki> ただ、ここで、小野小町が実身名なら、「小野小町」の歌ではなく人物像へのリンク
h1suzuki> を含んだ「私撰集」という実身が見つかるわけで、「小野小町の歌のある私撰集」と
h1suzuki> いう検索をしたい場合は、実身名より、仮身名や注釈機能からの複合検索になるだろ
h1suzuki> うなあ。まあ、小野小町の歌の名前を知っていたら、実身名とリンクだけで何とかな
h1suzuki> るだろうけど。

データに特定の構造が期待できれば良いのですけどね。
実身名に適切なキーワードが含まれていること以上に
期待薄です。

h1suzuki> | 私はむしろ「実身名は長く仮身名は短く」なるのが通常だと
h1suzuki> |思います。そうでない場合もあるかも知れませんが。
h1suzuki> |
h1suzuki> | 以上、要点は
h1suzuki> |1. 仮身名は互換性を考えなければ良い機能と思う。
h1suzuki> |2. 長い実身名は必要な場合がある。
h1suzuki> |3. 仮身名は長い実身名の代替にはならない。
h1suzuki> |
h1suzuki>
h1suzuki> そう言うことで、もう少し、「長い実身名の例」が欲しいです。
h1suzuki> それがホントに、実身内容を良く表しているのか見てみたい。

「Javaマニュアル」の例。

h1suzuki> 仮身名が短くと云うのは、又、別の意見です。そのことは目的によると思います。場
h1suzuki> 合によっては、林さんが仮身名に求めている物は、続柄で済んでしまうのかも知れな
h1suzuki> い。

一般的に、長い実身名の場合の仮身名は、実身名のうち
仮身の置かれるコンテキストで自明な部分を除いたもの
(もちろん整形はされるが)になると考えます。

h1suzuki> それから、仮身名と注釈機能の扱いの違いについても、もう少し、詰める必要がある
h1suzuki> と思います。

これは実身との関連性と、コンテキストへの依存度合い
の兼ね合いで決まると思います。

---
    林(takanori@ohsaki.meidensha.co.jp)