どうも、Aki です。
この ML に発言するのは、ML への参加申し込みをして以来ですね。
katsuhiro MIHARA さんの助けで、以後、Message Manager を快適に使用してい
ます。
いつも、無責任な発言で申し訳ありません。>おーる
# このメールは、もう、化けてないと思いますが。^^;;;;
# 大感謝 > MIHARA さん
# ちなみに Dialup なら電八の方がいいのだろうけど、
# 学校で LAN を引いてくれていますので Message Manager の方が
# 便利なのだ。ただ、英語版の95の上では、ESC をしっかり取り除
# いておくってくれるみたいだけど。(Binary なら Okey)
で、日々、1B には TCP/IP に対応してくれないかなーーーーと「お星様にお願
い」という程度に願っています。と言うことで、是非、B-free が TCP/IP をサ
ポートすることを望みます。>鈴木さんの意見に一票!
まあ、大変なのでしょうね。でも、やってることは、みんな大変だから、同じ
か。<おいおい
一時期、ML がかなり閑散とした時期もありましたが、最近、必ず毎日 2 発元
以上を見かけるのを見ると、excite して良いなあと思い、安心します。特に、
Night さんと 林さんの Debate 的意見交換は、ただただ、「良く知ってるなあ
」と。(^_^;
で、まだ、僕は堀の外から見てる感じなのですが、ファイル名の話が出たので
、一言最近思ってることを。相変わらず、無責任な発言です。でも、どう思う
?
「ファイル名のこと」
まず、言語を考えると、Latin 語圏は Alphabet であって、複数の文字で一語
を洗わすので、当然、多くの文字が一つのことを表すのに必要になる。もちろ
ん、B-free が英文なども扱う考えがある限り、Proportional Font と Fix Fo
nt を仮身の表示などOSの関わるところで自然に表示できることは、必須であ
る。これは、もう、文字属性とかを越えた次元であり、いわば、「日本語なら
Fix、英語なら Proportional 」くらい、英語で非一定幅の文字を表示できる
ことは、当たり前でなくてはならない。
ただし、ホントのことを言えば、日本語だって、特に縦書きは Proportional
の方がきれいに見えるし、英語だって、Program とかは、Fix の方が、Indent
がとれて上手い。要するに、そういったことは「太字・陰付き・色」などの他
の文字修飾情報と、一線を画する情報として扱った方がいいと思う。実装もそ
うすべき。
一方、「長い文字と実身の内容の関係」について考えてみると、長いファイル
名が良いとは必ずしも思えないと言うのが、最近の僕の中の流行だったりする
。情報を集積するとき、それぞれの情報にはそれぞれの見方があり、「今はこ
ういう見方として Strage に保存する」として実身・仮身 Model に<そういっ
た名前>で組み込んだとしても、以後、蓄えた情報の「検索&再構成&再利用」
を考えたときは、「別の見方をして、<別の見方をした名前>」で再度その情
報を実身・仮身モデルに組み込みなおしたい場合も当然あるはずであり、その
時
に長い名前だと検索に特別な機構を設ける必要があるし(例えば実身名の検索
に正規表現を取り入れるとか)、BTRON の最大の長所である、「実体は可能な
限り一つ」というのも難しくなる。
# 正規表現を、<特別>と見るかどうかは、意見が分かれるところ。
# でも、単純な検索は、かなりの高速化がはかれる事も事実。
# Hash さえも使えそうだし。
そこで、ファイル名は、
その内容を表すキーワードにすべき
であり、
内容を説明する、事実の「切断面」であるべきはない
という気がする。
もちろん、内容が確定的なものは、断面も何もなく、その「内容」そのものが
名前に使われ、内容は名前の Detail を造ることになるが、例えば、歴史的事
実などは実身名は「事実を表すこと。日付や事件名」であり、でも、仮身には
その「実身内容への見方」が表示されるべきである。そして、その「見方の記
述」こそ長い名前のファイル名を造る可能性のあるものである。
結論として、ある程度のファイル名の長さ(<32?)は、Latin 語圏を意識して用
意すべきであるが、そんなに長いファイル名を可能にしても実身名によくない
使い方(断片面の記述)を許すだけで、あまり、効率的にも利点はない。むしろ
、実身名に Alias の様なものを許し、仮身側の情報として管理すべきである。
いまの BTRON1 では続柄がかなり近い線を言ってるが、これは Table & Index
での管理で、他のファイルシステムに移行が不可能だし、続柄はむしろ「Yes
/No、処理済み、未決、緊急」などなどの付加的な(そして頻繁に保存される先
の実身・仮身 Network に関わりなく変化するような)情報に使用するためにあ
る。
そこで、その(ここではその Alias を仮にこう呼ぶ)「仮身名」を仮身レコー
ドの中か直後に新しい種類の可変長レコードとして置き、「仮身名」がなけれ
ば、実身名を素直に表示し、さもなければ、仮身名を仮身の表示に使う。と言
うのが、正解でないかしら。
まあ、互換性を考えて別レコードとした訳だけど、気にしないのであれば、仮
身レコードが可変長の時は仮身名を含むと云う事にしても良いよね。
# どう思う? > おーる
# でも、この発言は、ちょっと、Rather, FTRON?
In "[b-free 539] Re: ファイル名の長さ" with Naitoh Ryuichi ,
(11:58:01 PM +0900 in September 18,1997)
- night wrote.
|
|隆一です。
|
|
|From: Takanori Hayashi <takanori@ohsaki.meidensha.co.jp>
|Subject: [b-free 536] Re: ファイル名の長さ
|Date: Thu, 18 Sep 1997 16:18:04 +0900
|Message-ID: <9709180717.AA11946@clare.ohsaki.meidensha.co.jp>
|
|> 林です。
|>
|...[snip]...
|
|>
|> BTRON2では、実身属性は属性レコードという負のレコード番号を持つ
|> レコードで表されます(レコード番号ごとに属性が割り当てられている)。
|> これを素直に実装すると、ファイルヘッダにはレコードインデックス
|> だけを置いてレコードはデータレコードも属性レコードも別ブロック
|> に入れることになります。これだと実身名の長さはほとんど無制限に
|> 伸ばせます。(さすがに効率が悪そうですが)
|> もう少しましな実装は、属性レコードが固定サイズのもの、および
|> 可変サイズの属性でサイズが小さい場合はファイルヘッダ内に置き、
|> 大きいサイズの場合だけ外部に出す方法です。属性レコードの処理が
|> 多少複雑になりますが、現実的な実装と思います。
|> # データレコードにも同じ方法を取ると、1実身最低2ブロック使う
|> # 現状のものよりかなり効率を上げられそうですが…。
|
|ファイルの属性をレコードとして扱うかどうかという選択もありますね。
|属性をレコードとして扱うならば、可変長レコードにするだけで、ファイル名
の
|長さが可変長にできますから。
|
|
|> 以上、2点は新たにファイルフォーマットを作った場合の方法です。
|> そうでない場合、標準FDと互換性を持たせたまま長い実身名を付ける
|> 方法としては、長い実身名を特定のレコードタイプ、サブタイプの
|> データレコードとして表す方法があります。この場合、通常の実身名
|> の領域には長い実身名の初めの部分だけを入れます。長い実身名に
|> 対応していないシステムでは長い実身名は扱えませんが、それ以外に
|> 特に問題はないでしょう。
反対1。
これだけ(長い実身名の最初の方だけを通常の実身名に入れておく)は、絶っ
対、やって欲しくないです。70% は W95 が嫌い(長いファイル名(Long filen
ame)という単語すら嫌い。<長くないファイル名?)なせいかも知れませんが
、、、、。結局そういうことをしても、意味がないと云うのが、正直な話、理
由です。短い名前を付けるなら、長い名前と別のものをつける方が、絶対イサ
ギが良い。その方が、絶対、まとまりが付く。結局、互換性を考えなくてはい
けない File-system 先に情報を移したとき、せっかく BTRON1 の File-syste
m がファイル名に依存してないのに、仮身に表示する文字列が変化してしまっ
て、「何でそんな尻切れなファイル名に変換されてしまうかなあ」と云う感じ
です。「おお、仮身は全く別の文字列で表示されてしまったけど、意味は全然
変わってないよ。すごいぜ」のほうが、かっちょいい。そう思いません?
# まあ、そういう意味で、「仮身名」というのは有効でもある。
|
|標準 FD については、長いファイル名を使うことは考えていませんでした。
|標準 FD の場合だと、短いファイル名でしかアクセスできない OS がある
|ので、長いファイル名を扱えるようにするのは難しいように思います。
FD が、情報を移行する、唯一の手段???
;_;
書庫管理で圧縮して、ネットワークにも流せるよ!
|他の OS のようにひとつのファイルを複数のファイル名でアクセスできる
|ならば、Windows 95 のように短いファイル名と長いファイル名の併用も
|できるのですが。。。(でも、弊害はありそう)
BTRON は、名前の一過性に頼っていないから、あんまり関係ないんだよねえ。
検索の時くらいか。ファイル名が問題になるのは。
|
|ただ、BTRON には、ファイルシステム間でのリンクを張る機能があるので、
|それを考えると「非互換」ファイルシステムでも長いファイル名をサポー
|トするのはいろいろ問題がありそうです。
|
|# リンク情報の中にもファイル名が入っているんですよね?
|
ホントだ。Link-file を表す F_LINK 構造体に「参照ファイル」がありますね
(PH 1-122)。 あらら。参照先の File system に接続してない状態でも、ファ
イル名を表示するためですね。でも、Alias としての「仮身名」は仮身ととも
にあるわけだから、関係ないけど。
|
|> 以上、どの案も長い実身名を効率的に扱うことは考えていません。
|
|完全に予想にすぎませんが、多分、極端に長いファイル名を使うことは
|少ないと思います。
|長いファイル名を扱うときだけ特別扱いして、短いファイル名を効率よ
|くすることでいいと思いますが。
|
|
|ただファイル名を長くするだけでは芸がないので、ファイル「名」に TAD を
|使えるようにして、ファイル名を図形にするのも面白そうです。
|(この辺の話は、昔にも出ましたか)
|
うーん。時々こうすると便利なんだろうけどねえ。でも、せっかく、BTRON で
は Object Oriented に見切りをつけたのに、OO を促進するような機能だと思
いません? むしろ、こう云うのは、App の仕事で OS の仕事では無い気がす
る。例えば、
立ち上げると、最初のリンクを標準の App で起動して、自らは直ちに閉じる
。
という App と、「開いた仮身」を組み合わせるだけで、そんな機能は実現でき
てしまうでしょ。
もち、開いた仮身の時は、別の App に引数を渡して「開いた仮身の表示領域」
を描いてもらうという裏技的処理がいるけど。
ていうより、この処理を、「裏技的ではなくする」事は、B-free で是非やって
欲しいかも。:-)
|ただ、テキストエディタだけでは図形が扱えないので、プログラムを組むにも
|図形も扱えるワープロが必要になってしまいますが。。。
|スクリプト言語だと、仮身をそのままひっぱってこれるので、それほど問題は
|ないかもしれません。
|
|
|
|---
|B-Free プロジェクト実行中! 詳細はこの Web ページへ
|(http://www.b-free.orient.co.jp/)
|
|内藤隆一 (rnaitoh@st.rim.or.jp)
|
|
- Aki at Bridgewater.
p.s. 最近、開いた Window の pictgram を one click で、App の終了になっ
てくれないかなあと、ホントに、切望している。ただの、横着だけど。< だ
って、Opening との対称性くらいしか、二回たたく意味無いじゃーーん!!!
!!
--------------------------------------------------------------
Hideaki Suzuki (SO in Bridgewater State College)
e-mail H1Suzuki@Bridgew.edu
Home Page http://www.yashi.com/h1suzuki (Under Constr.)
Nifty-Serve KGH06253