[#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:3361] Re: meta programming features
けいじゅ@今はフリー(^^;;;です.
In [ruby-list :03357 ] the message: "[ruby-list:3357] Re: meta
programming features ", on Jul/16 08:44(JST) matz@netlab.co.jp
(Yukihiro Matsumoto) writes:
>|>Module#flavorsとかはどうでしょう? なんか違うものを連想しそ
>|>うですけど,メタ機能はあまり一般人は使わないと思うので,一般
>|>人が使わない語彙の方が良いのかなと.
>|
>|flavorsねえ... それなら, ruby風にmixinsのほうが... でも, それだと余計
>|誤解を生みますね.... あと, 思い浮かぶのは
>|
>| Module#modules
>| Module#inherits
>|
>|ぐらいですねえ...
>
>mixinだとモジュールだけだと思ってしまうでしょう?
そうなんですよ. でも, flavorsでも同じものを想像したりして(^^;;;
>今回はincludeされているモジュールと継承しているクラスの両方
>を含むリストなんですから,mixinでは良くないように思います.
>
>|> クラス定義メソッド
>|現在のコンテキストというのはそんな気がしますね. これに関しては, イテレー
>|タ部分はどうします?
>できれば使いたくないです.前のメール参照.
さっきの案はどうです?
>|> メソッド一覧メソッド
>|> モジュール(クラス)のものとオブジェクト毎のもの.
>|> 名前が問題だ
>|
>| Module#methods を採用しないのは, 何か理由がある?
>Object#methodsが欲しいから.つまり,特定オブジェクトのメソッ
>ドの一覧を返すメソッドの名前と,あるクラス(モジュール)で定義
>しているメソッドの一覧を返すメソッドの名前が重ならないように
>したいからです.両方ともmethodsにしちゃうと,クラスメソッド
>の一覧がとれなくなっちゃう.
そっかそっか. 忘れていた(^^;;;
Module#features
Module#protocol(s)
>|あとは, 機能追加に関するAPIが問題ですね.
>|クラス生成時にイテレータが指定できるのなら, それを流用しても良いし, ク
>|ラス生成時にイテレータの指定ができないのなら, どちらにしても, 関数や定
>|数定義のAPIが必要になりますよね.
>
>イテレータは採用したくないので,必要でしょうねえ.
1つ1つ考えていると結構大変なので... とおもいましたが, 良く考えると:
定数定義とメソッド定義のAPIがあれば, 後の機能(include/private...)は全
てメソッドで提供されているので十分なのかな?
あと, 可能性としては, イテレータかevalになるんでしょうかねえ... evalで
もバインディングを変更しないですむほう方法があるならそれでもいいんです
が...
話しはだいぶ変わるんですが, evalのbinding指定は結構使いづらいものがあ
るんですよねえ... あるbindingに別なbindingをマージした新しいbindingを
作るような機能は考えられませんか? 例えば,
bd.merge{foo = "Foo"}
の良うな感じです. ここでは, bdはあるバインディングでイテレータの持つバ
インディングをマージした新しいバインディングを作っています. そうすれば,
foo = "Foo"
bd.merge{}
みたいな使い方も可能になります.
__
.........................................石塚 圭樹@今はフリー(^^;;...
------->>また, アドレス変わりました!! e-mail: keiju@bc.mbn.or.jp <<---