# MIT は一般教養課程がありません。普通の州立大はあるのにさ。
In "[b-free 610] Re: 仮身名" with Takanori Hayashi ,
(10:59:47 AM +0900 in September 25,1997)
- takanori wrote.
| 林です。
|
|In message <199709241745.CAA04737@b-free.orient.co.jp>
| "[b-free 608] Re: 仮身名"
| "h1suzuki@bridgew.edu (Hideaki Suzuki)" wrote:
|h1suzuki> 僕もそう思います。>短すぎの識別子。
|h1suzuki> でも同時に、ファイル名に内容識別の全てを頼ってるために、ファイル
名が長くなり
|h1suzuki> がちなのも一因とは思えませんか? ファイルに付随する情報と言えば
「ファイル名
|h1suzuki> と保護属性のみ」というシステムですから。例えば、拡張子はその良い
例だと思うし
|h1suzuki> 。
|
| まあそうだけどね。でも
|h1suzuki> 実身名:各ファイルの「内容」を識別する名前である。
|と言ったのは君だよ。そして私には
|「どんなコンテキストでも実身の内容を正しく表す短い名前」
|が「いつでも」存在するとは思えない。
ん?
内容を識別とは、例えば、「JFK の暗殺」の事についてかかれた実身に「JFK の暗殺
」という名前を付けるとか、明治の開国のごたごたを集めた実身に「明治維新」とい
う名前を付けるとか、そう言ったことです。
# でも、明治のごたごたを「明治維新」以外の味方の出来る形で集めたなら
# 明治維新というのは仮身名の方で、実身名は「明治開国の混乱」とかになるだろ
うなあ。
そのファイルが「どんな保護属性を持っているとか」とか「どんな App で処理され
るかとか」とかは2次的なことですよね。そう言うのを、イッショコタにするのはな
あ、という事を云いたかったわけです。
あと、えっと、「いつでも」に対しては、
情報はある種の集まりがあって、ファイルを成すのですよね。その「ある種」という
のが実身名になるのでは? それは、Context-free な情報で、そのファイルが構成
される理由みたいな物です。
# ただし、「地と図」的見方で、そんな物は存在しないと言えるのかも知れない。
# 知らないけど。<とりあえず、上の JFK とかは適当に見えるから。
# 一方、「30文字では表せない数字」的に、絶対表せると云ってしまっても
# 良いのかも知れない。これも、知らないけど。
|h1suzuki> 20文字は、短すぎます。それには、異議はないのですがねぇ。
|h1suzuki> でも、まえに林さんがいったような「1Kもとれば」とかいうのは、「
それって実身
|h1suzuki> 名に何でもやらせ過ぎるからじゃないの?」って感じがしてなりません
。500文字
|h1suzuki> って事は、25文字*20行ですよ! そんなのをファイル名として受
け付けるのは
|h1suzuki> どうかな。情報の置き場所としてファイル名以外の適当なところがあり
そう!
|
| それはそうだけどね。では「何文字あれば十分か?」と言われたときに
|「XX文字あれば絶対大丈夫!」と答えられるかというと難しいのよ。
|少なくとも非常に大きな余裕を持って、それでも「おそらく」になる。
|それに、また「足りない」状況になっても困るので、仕様上は十分に
|大きく取っておきたい。それで200文字も取るなら実装上は幾らでも
|それほど変わらないから「無制限」にしてしまえということになる訳
|です。何か変?
文字数を決めると云うことは、即、固定長ファイル名の実装を許すと云うことですよ
ね。その辺が、僕は、惜しいんだよねえ。基本的に、僕は可変長が嫌いなわけ。<こ
らこら
TAD も文字は基本的に固定長じゃん。可変長は Escape-code による扱いになる。ま
あ、RISC な思想は持っていないけど、今まで固定長だった物を可変長にするのは、
一種抵抗みたいな物があります。
「長いファイル名 (Long filename)」という語感には、もっともっと、抵抗があるん
だけど。due to Win9$
# Win とかのファイルシステムって、どこに、あの8文字以上の情報をしまってる
の?
どちらにしろ、そういった、非論理的な所はおいといて。
いや、ここからは、まじめな話。
確かに、どこまであったら十分かというのは非常に状況に依存することがらですね。
言語によっても違うだろうし、付ける目的によっても違うと思う。
僕の目安としては、例えば、8.5x11 in. の Letter 用紙に横 1.5in のマージンを付
けると、標準的なサイズの Proportional -Times Roman で、一行 100 文字くらいに
なる。だから、100文字以下だと見積もるのはどうでしょうか?
言い換えると、「仮身内で改行なしに一般的な用紙幅をこえたりしない長さ」と言う
ことかな。
でも、これは 64 と 128 の中間なので、十分なら 64 に丸めてしまっても良いし、
足りないなら 128 でも対して変わりないという所かな。どちらにしろ、改行してま
でしないと一行に入らないような情報は、実身名とは別の所にしまいなさい。と、言
いたいね。僕は。
|h1suzuki> # 林さんが「TAD部 を実身名以外のファイル属性にしよう」というの
は同意という
|h1suzuki> より好感が持てます。
|h1suzuki> # でも、それも、実身に付随する情報なのか? という疑問は残りま
すが。
|h1suzuki> # 実身に付随する TAD の情報って、単なる「TAD 主レコード」じゃな
いの?
|
| いや仕様にも「注釈TADレコード」とか「補助TADレコード」とかあるよ。
|まあ属性ではなくてデータだけど、属性とデータを区別する必要性は
|必ずしもないと思うし。
!!!
このこと(注釈レコードとか)はすっかり忘れてました。
何せ使われてないから。^^;;;
プロハンを見る限り、実身に対する補助的情報の追加に関して、
注釈レコード: 実身に対する「直接表示される部分」と関係ない情報をしまう。
補助レコード: それ以外の、効率などのための雑多な情報をしまう。
という理解で良いのかな。
すると、実身名を長くしたいというのなら、この、注釈レコードを使用するかも知れ
ないと言う理解で良いですね? 仮身にこの情報を表示しようと言うのですか? そ
れは、まだ賛成できないけど。
それとも、実身名自体は今までと同じ場所にしまわれ、この注釈レコードには、全く
新しい情報の置き場(まさに注釈)としての地位を、与えると言うことですか? UIが
少し変わるかも知れないけど、仮身の他に注釈を表示できるようにすると。「注釈機
能」とでも云うような。それが、例えば、商標や会社のマークだったり、制作者の情
報だったり。そう言うことですか? もち、実身の「管理情報」を見ると「注釈」と
いう項目があって、そう言った物が表示されるのですよね。
# それは、「仮身名」とは別の魅力的な idea ですね。
|h1suzuki> # 要するに、仮身に、実身名以外の、仮身に付随する情報が表示でき
たら、嬉しい
|h1suzuki> のだ。
|h1suzuki> # 「もっと自由な続柄」見たいのね。すなわち、仮身名。
|
| たとえば図形実身のプレビュー画像をアイコンみたいに表示するとして
|これを仮身に入れるの? こういうのはやはり実身に付属する情報だよ。
???
「開いた仮身」じゃだめなの?
どうせ、表示領域は、標準の App が書くんだし。
# ああ! やっぱり、One-Click Open & One-Click Close の方が Double-click
より
# 優れているんだ。だって、開いた仮身とか、本物のボタンみたいに機能するもん
。^^;;;
|h1suzuki> Java は、あれは Alphabet でファイル名をきめてますからねえ。そりゃ
あ、ファイ
|h1suzuki> ル名も長くなります。
|h1suzuki> そうだねえ。でも、そのことを考慮しても、50文字もあれば足りるん
じゃない?
|h1suzuki> 統計を取ってないから、全然判らないけど。
|
| Javaのフルスペルは「パッケージ名.クラス名.メソッド名」の形式
|だったと思うけど、50文字で足りる?
| この話は、階層化されたコンテキストの中でのクラス名なりメソッド
|名を実身名にするのではなくて、「コンテキストに依らない識別子」
|としての実身名が要求される場合だからね。
この点については、僕の、「b-free 609 自己FOLLOW」を参照してください。と言う
ほど、詳しく書いてませんが。
Java などの「旧式ファイルシステム」の上の名前の一過性に頼った言語は名前の結
合を使わないと、Overload などで上手くありません。ですから、実身名自身が Met
hod 名を Full spelling する事は無いと思います。
例を出すと、
******** ある実身の中身(一つの Package を形成する) ********
import [仮身1]; // (comment より仮身名?)別のパッケージの輸入
class クラス名1 [クラスの実装をした仮身1]; // 実装と識別子の結合。
class クラス名2 [クラスの実装をした仮身2]; // 実身名はどうでもでも良い。
class クラス名3 [クラスの実装をした仮身3];
***********************************************************
という具合に、Package を形成し、各クラスの実装では、
******** ある実身の中身(一つの Class を形成する) ********
import [仮身2]; // 他のクラス名(i.e."クラス名2") を使うのに必要。
extends 下位クラス(基底クラス); // 継承とかに使う名前も import した物。
methodA [method を実装した仮身1];
methodB [ほにゃららという処理];
methodC [○○という処理]; // 多重定義は、仮身より名前が良い。
methodC [Overload してみる仮身];
*********************************************************
と言う具合にしないと、もう、実身仮身ネットワークの自由度が、識別子の使用制限
を破壊しまくりだし、多重定義は良いけど、同じ名前の意味があんまり無い(読みや
すさに貢献するぐらい)とかで、「なんだかなあ」という Java になってしまいます
。まあ、今まで実身仮身ネットワークみたいなのに、まじめに言語を載せた人がいな
いんだから(!)、ちょっと、よく考えてみないと気づかん事だろうけど。
|h1suzuki> 何でも実身名に詰め込んでいく方向性か、どんどん実身名を単純化(単
一化)してい
|h1suzuki> く方向性か。
|
| それは実身名に「コンテキストに依らない識別子」を求めるか
|一定のコンテキストで意味を持つ「キーワード」を求めるかの
|違いですね。識別性は簡潔性と必ずしも両立しませんよ。私はね、
|どちらでも良いと思っています。そしてどちらをも必要に応じて
|選べるように、技術的な制限は少ない方が良いと思います。
そうですね。「Keyword v.s. Identifier」はすごく良い描写だと思います。
僕の見方では、Identifier は十分に簡潔になれるという立場にいるわけで、その辺
の状況理解(認識?)がもう少し必要みたいです。
で、技術的な制限の少ない方を取るのは無難なんですが、僕はそこで、B-free に P
olicy を求めていた(いる)わけです。あまりに自由度が大きいのは、時に混乱を招く
というのは周知の事実。まあ、両方試してみてから、Policy を選ぶという方法が B
etter かなぁ。
# 日本は、未だに Non-poli. の時代?
# U.S. は、Policy の前に、Individual があるから最初に「勝手にすれば?」と
いう事になるけど。
# 知らないけどさ。
|h1suzuki> | 仮身名を否定するものではないけど、要求の内容だととりあえずは
|h1suzuki> |運用かアプリケーションで解決がついてしまいそうですね。
|h1suzuki>
|h1suzuki> えっと、仮身名をサポートするというのは、それこそ、「どこでも出来
る」という事
|h1suzuki> を意味します。例えば、表計算の中やマイクロカードの仮身フィールド
でもです。
|h1suzuki> これって、「基本の部分としてサポートする v.s. 追加品として対応す
る」の違い
|h1suzuki> ですね。
|h1suzuki> 新しい App がでる度に「そうできる物と、出来ない物がある」というの
では、あま
|h1suzuki> りに、仮身というせっかくの普遍的データが、もったいない。^^;;
|h1suzuki>
|h1suzuki> その辺って、Enableware や BTRON の実身仮身が「後から付け加えた物
ではないから
|h1suzuki> 、どんな App とも連携機能する」とかそう言ったことと、同じ議論じゃ
なかったっ
|h1suzuki> け?
|
| そうだよ。でも「どこでも」というなら非対応システムに
|持っていっておかしくなるようなものでは困るでしょう。
| 下位互換がいらないなら「仮身名」は良い機能でしょう。
仮身名を普遍的に使うという立場をとるなら、やはり、System の仮身名として sup
port するべきですよね。App の運用で誤魔化すべきではない。でも、
「下位互換がいらないなら「仮身名」は良い機能でしょう。」
って、どういうこと?
|h1suzuki> | 先に書いたように前提に問題があります。中立的な識別子は短くなる
どころ
|h1suzuki> |か色々な要素を取り込んで非常に長くなる可能性があります。そのよう
な場合
|h1suzuki> |無理に短縮すればそれこそ一面的な見方になるでしょう。
|h1suzuki> | 仮身名を否定する気はありませんが、少なくとも長い実身名への要求
を代替
|h1suzuki> |できるものではないと思います。
|h1suzuki>
|h1suzuki> これは、今一つピンとこないなあ。
|h1suzuki> 中立にするために「ながーくする」ってどう言うこと?
|h1suzuki> 普通、長くなればなるほど Specific になって、うーん。使われ方に密
着した情報に
|h1suzuki> なる気がするんだけど。すなわち、仮身よりになるって事。
|h1suzuki>
|h1suzuki> 例があったら出してください。
|
| Javaの例。メソッドごとに実身を分けたヘルプファイルを考え
|ましょう。メソッド名を実身名にしたら、それは特定クラスの
|文脈でしか識別性がありません。メソッド名で検索してみたら
|同じ名前の実身がごろごろ出てきて、それぞれ開けてみないと
|なにがなんだか分からないと。フルスペルの実身名を付ければ
|これは中立した識別子で、どういう文脈でも実身を正しく識別
|できます。
これは、まず、Java をあのまま実身仮身ネットワークに持ってきた場合の話ですよ
ね。それは「おかしな移植法だ」と言うことは述べたとおりです。実身仮身ネットワ
ークにするなら識別子への結合が必要になると思うし、そうしないのなら今までと同
じ扱いのファイルで、Java を組むことになるでしょう。変に実身仮身にしない方が
いいと云うことです。
# まあ、構造化言語が構造化ファイルシステムに適するのは
# 当たり前だという意見があるのだけど、考えて見れば実身
# 仮身ネットワークとは、構造化ファイルシステムより更に
# 自由度の高い hypermedia 形式のファイルシステムな訳だ。
# 単なる構造化と思っていると、高すぎる自由度が仇になる。
林さんの、おっしゃっていることは、ちょうど Assembler で、Record-name に取り
囲まれていながら、Member-name が外に公開されてしまって、仕方ないから member
の名前の頭に Record の名前を追加するように聞こえるのですが、正しい idea で
すか?
どちらにしろ、実身名を識別子に結合することで、更に、自由な名前が関数とかに付
けられるのは確かです。しかも、実身名を変更しても、プログラムに影響はないし。
たとえ Java compiler がハングルに対応して無くても、実身名では使えますしね。
|h1suzuki> | そのような実身名変更は間違っています。「JDK 1.1.1」と「JDK 1.1
2」は
|h1suzuki> |別の物でしょう?
|h1suzuki>
|h1suzuki> えっと、では、JDK 1.1.1 を、その各種ファイルが入ったキャビネット
と考えてみて
|h1suzuki> ください。
|h1suzuki> キャビネットの中身を入れ替えて、JDK 1.1.2 にしてみました。という
のは?
|
| 普通は実身を(浅く)複製して変更しますね。
浅いというのは、木構造ではないので、よくハッキリしませんが。
|h1suzuki> リンクする側では、何も変更せずに、最新の Version にリンクしている
ことが保た
|h1suzuki> れますね。で、このキャビネットの中に、JDK 1.1.1 へのリンクがある
ことは、ぜー
|h1suzuki> んぜん Okey です。この新しい JDK1.1.1 キャビネットには、古い JDK
1.1.1(いま
|h1suzuki> JDK1.1.2 )のファイルがリンクされているのですけど。
|
| そういうのは「最新パッケージ」というキャビネットに
|「JDK 1.1.1」を入れておいて入替えるか、続柄で「最新」
|を付けておくかするのが、正しい処方かと。
| 直接リンクの中身を下手に変えると、互換性が取れなくて
|動かないものが出るかもよ。
「動かないもの」とは?
もすこし、具体的に云ってくれると、想像できるかも。
続柄は、ネットワークを越えては使えないのは、承知のことと思います。何せ、シス
テムに固有の table&index で文字列を表示してますものね。だから、最新という続
柄を付けるのは、仮身を持っている Client の仕事になりますね。これは機能しない
と思います。
「最新パッケージ」は、僕の JDK1.1.1 という名前を置き換えただけで、とくに同じ
Analogy に聞こえますけど。
そだなあ。Client からみて、
1 JDK111 という仮身を貼っておき、Server の実身名変更と内容変更で、JDK11
2 にする。
2 最新パッケージ という仮身を貼っておき、内容変更だけで済ます。
さて、どちらに、どういう利点があるでしょう? 2だと、いつ中身が更新されたの
か、一目瞭然というわけには行かない? まあ、更新日時を実身名に入れればいいか
。でも、それだと1も2もやってることは完全に一致する。1だと JDK 111 の仮身
をコメントなしで引用できる(Context-free)。別の言葉で言うと、「最新パッケージ
」とは2次的な情報である。という事ね。
# 2次的な情報を実身名で使うべきかどうか、どこまでやって良いのか。
# 個人の自由なだけに、ガイドラインが欲しい。
# > "HOW TO BTRON" 出版なる?!
|h1suzuki> | 短くすると逆にヒットしすぎて意味が無くなるかも。検索結果一万件
に
|h1suzuki> |なっても意味ありますか?
|h1suzuki>
|h1suzuki> これはおかしいと思う。
|h1suzuki> ヒットは出来るだけした方がいい。
|h1suzuki> で、後は絞り込めばいい。
|h1suzuki> Inforseek とか見て、そう思いません?
|
| 実身名が長くても部分一致でヒットする分には同じだけど(^_^;)。
|短い名前だと、あとの絞り込みにはもはや実身名は使えない。
|結果として全文検索しか手がなくなるような気がします。
うーん。全文検索まで行かなくとも、貼ってあるリンクで絞り込むとか。例えば、
「私撰集 で 小野小町を含む物」とか。
ただ、ここで、小野小町が実身名なら、「小野小町」の歌ではなく人物像へのリンク
を含んだ「私撰集」という実身が見つかるわけで、「小野小町の歌のある私撰集」と
いう検索をしたい場合は、実身名より、仮身名や注釈機能からの複合検索になるだろ
うなあ。まあ、小野小町の歌の名前を知っていたら、実身名とリンクだけで何とかな
るだろうけど。
# ちょっと、この実身名の特殊さが感じ取れてもらえたでしょうか。
# 「小野小町」は「歌」では無いのです、「人」なのです!
# すると、<含む>という表現は、どのくらい深いリンクまで
# 含んでいるかという問題になるが。
| 私はむしろ「実身名は長く仮身名は短く」なるのが通常だと
|思います。そうでない場合もあるかも知れませんが。
|
| 以上、要点は
|1. 仮身名は互換性を考えなければ良い機能と思う。
|2. 長い実身名は必要な場合がある。
|3. 仮身名は長い実身名の代替にはならない。
|
そう言うことで、もう少し、「長い実身名の例」が欲しいです。
それがホントに、実身内容を良く表しているのか見てみたい。
仮身名が短くと云うのは、又、別の意見です。そのことは目的によると思います。場
合によっては、林さんが仮身名に求めている物は、続柄で済んでしまうのかも知れな
い。
それから、仮身名と注釈機能の扱いの違いについても、もう少し、詰める必要がある
と思います。
それでは、また。
- Aki at 瞼が重いモード
--------------------------------------------------------------
Hideaki Suzuki (SO in Bridgewater State College)
e-mail H1Suzuki@Bridgew.edu
Home Page http://www.yashi.com/h1suzuki (Under Constr.)
Nifty-Serve KGH06253