[#3249] ruby for mswin32 — KIMURA Koichi <kkimura@...>
[#3257] mini-reference (syntax) — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
[#3305] Observable#notify_observers — shugo@... (maeda shugo)
前田です。
[#3312] multi-line comment — shugo@... (maeda shugo)
前田です。
[#3329] meta programming features — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろ%最終出社日です
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
[#3350] [Q] eql? and == — keiju@... (Keiju ISHITSUKA)
けいじゅ@今はフリー(^^;;です.
[#3375] Exception — keiju@... (Keiju ISHITSUKA)
けいじゅ@今はフリー(^^;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
[#3378] ML分割 — takagi@... (TAKAGI Hiromitsu)
ところで、話は変わって、ひとつ提案です。
[#3403] sorry for ruby-list trouble — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
[#3411] no cbreak in curses module — Shoichi OZAWA <ozawa@...>
こんにちは 小澤@日立 です。
[#3417] [Bug] String#sub — shugo@... (maeda shugo)
前田です。
[#3429] [Req] println — shugo@... (maeda shugo)
前田です。
まつもと ゆきひろです
[#3434] [Q] Thread — keiju@... (Keiju ISHITSUKA)
けいじゅ@今はフリー(^^;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
前田です。
前田です。
前田です。
けいじゅ@今はフリー(^^;;;です.
<199707301029.TAA25172@hoyogw.netlab.co.jp> の、
けいじゅ@今はフリー(^^;;;です.
<199707311103.UAA08460@hoyogw.netlab.co.jp> の、
[#3470] [Problem] for local class — keiju@... (Keiju ISHITSUKA)
けいじゅ@今はフリー(^^;;です.
[#3502] Re: .to_f result — 渡辺博文 <VYV01212@...>
わたなべです.
[ruby-list:3348] Re: module context and dynamic class define [Re: meta programings]
けいじゅ@今はフリー(^^;;;です.
In [ruby-list :03347 ] the message: "[ruby-list:3347] Re: module
context and dynamic class define [Re: meta programings] ", on Jul/15
03:28(JST) matz@netlab.co.jp (Yukihiro Matsumoto) writes:
>|こうやって考えると, クラスのパス表現はクラスの一意性のためになくてはな
>|らないものと考えた方がいいんですかね?
>
>そう考えた方がよいです.が,いつでも信頼できるパスが生成でき
>るわけではないんですね.たとえば,今回のようなクラスを生成す
>るAPIを用意してしまえば,かならずしもパスでアクセスできない
>クラスをつくってしまうことが出来るわけです.
これはそのようなAPIを作った場合ですよね? 今のところは, このパスが識別
子となっているわけですよね?
この考えはこのまま維持した方が良いのでは? と思うのですがどうなんでしょ
う?
>|foo = Module.new("class-name", super_class, upper_class) {...}
>
>upper_classの定数として新しく定義されたモジュールがバインド
>されるわけですね.そういうことを強制できるんでしたら,パスの
>問題は確かになくなりますね.
そうです. upper_classが省略されたらトップレベルで定義されるということ
で.
>| a = Foo::Bar::Baz
>| module a
>| ...
>| end
>
>この場合,module/classは積極的に既に存在するクラスやモジュー
>ルを拡張する機能を持つことになりますね.今はクラスの機能拡張
>は「おまけ」的な扱いなんですが.
うーん. なるほど確かにそうでしたね. 積極的に宣伝していませんね(^^;;;
既存クラスの機能拡張は, あまり望ましくないんですかねえ?? それではこれ
はどうでしょう?
foo = Module.new("Baz", nil, Foo::Bar) {
...
}
つまり, 先ほどの動的クラス生成のメソッドで, そのクラスがすでに存在して
いる場合は新たにクラスを生成せずにそのクラスをそのまま返し, さらにその
クラスのコンテキストでイテレータを評価する.
というのは? これだと動的クラス生成機能のおまけとして, 動的クラス機能追
加ができるようになります. これだと, (静的)クラス定義と対象性があってい
いかも知れない?
>|何か誤解があるかな? ソースコードを文字列として生成してevalして, メソッ
>|ドを定義できればいいだけですけども...
>なんか誤解があるみたい.^^;;;
まあいいでしょうこっちは(^^;;;
__
.........................................石塚 圭樹@今はフリー(^^;;...
------->>また, アドレス変わりました!! e-mail: keiju@bc.mbn.or.jp <<---