***
申し訳ない。 [b-free 881]で
Shift+1 が、Ctrl+Q になって、送られてしまった。
と言うことで、Iijima さん。訂正前のは、FTRON にあげないで、消しちゃって下さい
。毎度、済みません。 m(_._)m
# あと、削除を前に頼んだ方の発言は、Iijima さん他、みなさんが
# 気にしないと言うのなら、削除しなくても結構です。
# 個人的には、多少恥ずかしい物はあるが。(^^;;;;
***
ども。Aki です。
もうそろそろ、ねよっかなとか。。。。
Iijima さんが優しい事言ってくれたし。^^;;;
>Thanx!!
[b-free 811] Night さん
|いやだから、気楽に名前をつけたいような文書(実身)に対しても、「注釈機能
|で(頭をしぼって> 、時間を掛けて)書けば? 実身名だけでは語れない色々
|なことを、思う存分語ってみて。」ということをしたくないわけですよ。
|そういう、気楽に作るような文書については、長くて何も考えていないような
|名前をつけたいわけです。
|どうも、Hideaki Suzuki さんの意見を読むと、文書を作るという感じで、
|内容が 1 行か 2行程度の短いメモ程度の実身をポロポロ作っていくような人
|のことを考えていないような気がします。
そうですかねぇ。
別にそういうわけではないと思います。
むしろ、そういった長い名前の実身って、中身は最初はほぼ空なんですよね? だっ
て、一行か二行のメモ程度に実身名を利用するのと変わり内です物ね。
そうなると、いっそのこと、実身名長は0でも良い。という前に冗談で出た方針を採
用しますか?
実身名の長さを0にすると、実身内容が直接仮身に表示される(なぜなら開いた仮身
と変わらないと考えて)。で、あとで、その実身の内容を発展させて題名が付けたく
なったら付けたらいいじゃないですか。「展開印刷」がつかえると言う利点はありま
す。^^;
# まあ、それは、1Bだったらの話で、B-free とは関係ないけど。
# そうだ。仮身化は、実身名が無い実身として良い例になりそう。
[b-free 813] Night さん
|簡単にいうと、
|「実身名に大量の情報を入れる必要があるならば、長い実身名が必要である」
|ということですよね?
|
|これは、いっぱい入れないともったいない、という考えと等しいとは思いませんが。
うーん。それは、僕と Night さんの言った事が違ったからでしょう。
僕が言った
「実身名に大量の情報を入れる必要がないなら、長い実身名は必要ありません。」
から、
「長い実身名を使用しなければならない事になったら、実身名に大量の情報を入れな
いと良くない」
は(的外れな解釈ではあるけど)直接「僕が言った事」として導けるけど、
|「実身名に大量の情報を入れる必要があるならば、長い実身名が必要である」
というのは、Night さんの意見で、僕はそのことにはふれてないよ。と、単に揚げ足
を取っただけです。なぜなら、
|> 実身名に大量の情報を入れる必要がないなら、長い実身名は必要ありません。
|
|えーと、では大量に情報を入れる必要がある人にとては、長い実身名は必要な
|わけですよね。
という風に、僕の言った事を別の見方で再解釈するような事を言ったので。
だから、特に気にしないで下さい。^^;
本論とは関係ないです。
で、別件として、「大量に情報を入れる必要がある人にとては、長い実身名は必要」
かと聞かれれば、yesと答えます。
そういうわけで、
|> 「長い実身名を使ってはならないなら、大量に情報を入れる必要がある人は全くい
な
|> い」
|
|というのは、どこで書いたのでしょうか?
というのも、僕自身の意見をひっくり返したように、Night さんの意見を矛盾が起き
ないようにひっくり返しただけです。
そのほか、僕の屁理屈がすこし続いたので、それは cut....
|> 運用上の役割をもう少し限定しないでよいのですか?
|
|うーん、X window system のように、(BTRON という)メカニズムは提供するが、
|(運用方法という)ポリシーは提供しないという考えではダメですか?
結局、これで行くと言う事ですね。
それは、B-free が free であるからでしょうか。
そうだというなら、たぶん、理解したと思います。
# というより、それがポリシーですものね。
|結局、バイト列が等しければ、同じファイルだという単純な比較ではすまない
|わけです。
これは、かなり、severe ですね。
英語の alphabet は、日本語の alphabet とは別物という事ですよね。各コードマッ
プの相互変換の関数を作るのは、でも、B-free の仕事を遥かに越えますから、本家が
仕様を出すのを待つか、もしくは、当面は別物として扱って良いのではないでしょう
か。
# 英語・日本語のみでなく、日本語・中国語・韓国語とかある
# だろうし。そういうのを、ad hoc で OS に取り入れるべきでは
# 無い気がする。
|> # 小さい写真 -> 300lines * 76 = 22800 bytes
|>
|
|64Kbps だとせいぜい、1,2 秒ですが。。。
そだね。。。^^;
やっぱ、Nif のせいかも。
でも、文字ベースが絵を扱うことで、どれだけ処理が大きくなるかの指標には成るよ
ね。
|> うーん。100文字ですか。
|> 図形はそれぞれ、1文字ですか?
|> それなら、図形情報を他の実身上に持って、その実身 ID を文字コードとして使う
「
|> ローカルコード」みたいなのを、システムで支援しても良い気がするなあ。だって
、
|> 「文字」だもん。:-P
|
|それをネットワークワイドな環境で使うのは、難しいのでは?
外字ですから、それは、そんなには考えていませんでした。一つ方法として、実身仮
身マネージャで、実身IDを実身名の中に見つけたら、参照される側にその実身を送
ってもらうように頼むことが考えられます。これは、remote 上の開いた仮身を開くの
とそんなに cost は変わらないと思いますが。
# むしろ、「文字」であるから cache が効きそう。
[b-free 818] Night さん
|うーむ、必要(であろう)実身名の長さについて、発言していない人の意見も聞
|いてみたいです。
|
|# ということで、発言していない方よろしく。
かさねて、僕からも宜しく。^^;
長い実身名は認める方向にありますが、でも、「どの長さをもっとも効率的に扱うよ
うに設計すべきか」という話はまだある気がする。API とかも変わってくるし。
|一旦、制限をつけてしまうと、制限をはずすのは大変ですから。
|すでに、1B で採用した準 TAD によって、本来の TAD の形式の仕様は
|消え去ろうとしているように見えます。
そのように「設計」したら、もはや制限ではなく仕様に成ってしまいますね。1Bで
32バイト超の情報をプロセス間メッセージに載せられないのも、「仕様」。^^;