[#11357] [PATCH] an analogue of `long long' — "Nobuyoshi.Nakada" <nobu.nakada@...>
なかだです。
まつもと ゆきひろです
えぐち@エスアンドイー です。
まつもと ゆきひろです
えぐち@エスアンドイー です。
まつもと ゆきひろです
>From: matz@zetabits.com (Yukihiro Matsumoto)
まつもと ゆきひろです
[#11440] class Character (was: Ruby I18N) — Yasushi Shoji <yashi@...>
[ruby-dev:11428] からの続きですが、threadは切りました。
高橋征義です。用語について。
At Wed, 8 Nov 2000 20:44:55 +0900,
高橋征義です。
At Thu, 9 Nov 2000 13:30:34 +0900,
まつもと ゆきひろです
[#11447] gets は secure? — Kazuhiro NISHIYAMA <zn@...>
出力がInsecureなのに入力はsecureなのでしょうか?
[#11467] debug write in regex.c? — "Nobuyoshi.Nakada" <nobu.nakada@...>
なかだです。
[#11500] rb_to_integer/rb_to_int — "Nobuyoshi.Nakada" <nobu.nakada@...>
なかだです。
[#11520] A problem of Socket methods on Windows — OKA Toshiyuki <oka@...>
岡と申します。
なかだです。
まつもと ゆきひろです
なかだです。
岡です。
なかだです。
なかだです。
岡です。
なかだです。
[#11569] blocking on socket? — Shugo Maeda <shugo@...>
前田です。
[#11591] object.c パッチ — Kazuhiro NISHIYAMA <zn@...>
使われてなかったnil_plusの削除とOBJ_INFECTへの変更です。
[#11611] return value of waitpid2 — Koji Arai <JCA02266@...>
新井です。
まつもと ゆきひろです
荒井です。いや、新井です。(よくあることさ)
まつもと ゆきひろです
新井です。
新井です。
[#11618] Re: class variable — "Koji Arai" <jca02266@...>
新井です
なかだです。
まつもと ゆきひろです
> まつもと ゆきひろです
まつもと ゆきひろです
まつもと ゆきひろです
新井です。
[#11641] eval too slow — Wakou Aoyama <wakou@...>
青山です。
[#11650] conflict of NODE_DREGX_ONCE — "Nobuyoshi.Nakada" <nobu.nakada@...>
なかだです。
まつもと ゆきひろです
[#11662] IO (Re: fork problem?) — Tanaka Akira <akr@...17n.org>
In article <E140cR3-0002ls-00@ev.netlab.zetabits.co.jp>,
まつもと ゆきひろです
In article <E140fxW-0002u9-00@ev.netlab.zetabits.co.jp>,
In article <hvor93w5wb8.fsf@coulee.m17n.org>,
In article <hvoofz05uwz.fsf@coulee.m17n.org>,
まつもと ゆきひろです
新井です。
まつもと ゆきひろです
In article <E141eaC-0003w0-00@ev.netlab.zetabits.co.jp>,
まつもと ゆきひろです
In article <E142ZqF-0004rX-00@ev.netlab.zetabits.co.jp>,
まつもと ゆきひろです
In article <E143Zem-000271-00@ev.netlab.zetabits.co.jp>,
まつもと ゆきひろです
In article <E143amj-00028V-00@ev.netlab.zetabits.co.jp>,
[ruby-dev:11456] Re: Ruby I18N
In article <20001109202517.BE13.GGB03124@nifty.ne.jp>, "たけ(tk)" <ggb03124@nifty.ne.jp> writes: > まあ、僕が反論してのしょうがないのですが、まつもとさんの説得阻止という > 意味で・・。 > > 最近、転向しまして、「文字とは個数が1の文字列(一文字文字列)である」 このような見方はべつに珍しいものではありません。松本さんが python では そうであると指摘していますし、数学ではスカラと長さ 1 のベクトルないし は 1*1 の行列を同一視するという流儀があります。プログラミング言語とし て、文字以外の一般のオブジェクト列に対してこのような見方をするものには CafeOBJ (や OBJ3)があります。まぁ、CafeOBJ をプログラミング言語と呼ぶ と、仕様言語と呼べ、と指摘が入ってしまうかも知れませんが。 > という立場をとることにしたんです。 str[n] ではなくて str[n,1] で一文字 > 文字列を取り出して「文字」として扱えば十分な気がするのです。どうなんでしょ > う?。何か不都合ありますか?。 むしろ望ましいと思います。 (と <hvon1fbtg0v.fsf@coulee.m17n.org> にも書いた。) > 》* 文字コードが隠蔽される。 > > について、もし str[n] で文字コードが出てしまうのがうれしくないのであれ > ば、 str[n] で一文字文字列が出るようにすればよい。 いいんじゃないでしょうか。 > 》たとえば、mail/news の引用を考えます。この場合、届いたメッセージと自分 > 》で書いた部分をまとめることになります。この場合、まとめた結果を表現可能 > 》な MIME charset が存在する保証は存在しないわけです・・ > > 考えてみれば、このような状態(マルチ文字コード系の文字列)では全体として > の文字列を扱うというのは困難になる。これを、今までの Ruby で気軽に扱えた > ような文字列にするためには大変なオーバーヘッドを覚悟しなければならなくなる。 効率についてははっきりしたことはわかりません。そんなにひどくはならない んじゃないかという気がしていますが、確信があるわけではありません。 > しかも、このようなマルチ文字コード系文字列を扱うために「文字クラス」が > 不可欠というわけではない。「一文字文字列の配列」でマルチ文字コード系文字 > 列をとりあえず作っておき、それの扱いが普通の文字列と同じように作っていく > ということも可能。 もちろん、可能でしょう。 > * 「一文字文字列」のサイズが気になるのであれば、「文字クラス」と「文 > 字列クラス」とに共通の上位クラスを作って、「文字クラス」は単一の文字コー > ドを持つ、「文字列クラス」は文字コードの配列を持つ、というようにすればい > いのかな?。 それも悪くないかも知れません。 > その他の点について、 > > 》* 文字の取り違えが起きない。 > > 》* polymorphism を実現できる。 > > 》 他の例をあげるとすれば、文字自身にそれを表現可能な MIME charset を尋 > 》 ねる、とか。 > > 》* 付加的な情報を保持できる。 > > 》* 文字列の種類と文字コードの対を Array などを使ってアプリケーションが > 》 自力で管理するよりはずっとましな性能が得られる気がする。 > > 》結局、文字をオブジェクトにする利点は OOP の利点そのものです。 > > これらの各点については、「一文字文字列」でよければすでに達成されているは > ずです。 そう思います。 -- [田中 哲][たなか あきら][Tanaka Akira] 「くっだらないコト聞いちゃったねー$(C⊇ ごっめーん$(C⊇」 (魔法使い養成専門 マジックスター学院 2, 南澤ミヅキ)