[#3305] Observable#notify_observers — shugo@... (maeda shugo)

前田です。

22 messages 1997/07/09

[#3329] meta programming features — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

44 messages 1997/07/11
[#3330] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/11

けいじゅ@今はフリー(^^;;;です.

[#3332] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/11

まつもと ゆきひろ%最終出社日です

[#3340] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/14

けいじゅ@今はフリー(^^;;;です.

[#3343] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/14

まつもと ゆきひろです

[#3345] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/14

けいじゅ@今はフリー(^^;;;です.

[#3346] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/14

まつもと ゆきひろです

[#3349] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/15

けいじゅ@今はフリー(^^;;;です.

[#3352] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/15

まつもと ゆきひろです

[#3353] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/15

けいじゅ@今はフリー(^^;;;です.

[#3357] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/15

まつもと ゆきひろです

[#3361] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/16

けいじゅ@今はフリー(^^;;;です.

[#3365] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/16

まつもと ゆきひろです

[#3366] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/16

けいじゅ@今はフリー(^^;;;です.

[#3391] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/18

まつもと ゆきひろです

[#3398] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/19

けいじゅ@今はフリー(^^;;;です.

[#3401] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/19

まつもと ゆきひろです

[#3406] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/22

けいじゅ@今はフリー(^^;;;です.

[#3410] Re: meta programming features — matz@... (Yukihiro Matsumoto) 1997/07/22

まつもと ゆきひろです

[#3415] Re: meta programming features — keiju@... (石塚圭樹 ) 1997/07/23

けいじゅ@今はフリー(^^;;;です.

[#3375] Exception — keiju@... (Keiju ISHITSUKA)

けいじゅ@今はフリー(^^;;です.

19 messages 1997/07/17
[#3383] Re: Exception — matz@... (Yukihiro Matsumoto) 1997/07/18

まつもと ゆきひろです

[#3388] Re: Exception — keiju@... (石塚圭樹 ) 1997/07/18

けいじゅ@今はフリー(^^;;;です.

[#3392] Re: Exception — matz@... (Yukihiro Matsumoto) 1997/07/18

まつもと ゆきひろです

[#3403] sorry for ruby-list trouble — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

18 messages 1997/07/22
[#3404] Re: sorry for ruby-list trouble — keiju@... (石塚圭樹 ) 1997/07/22

けいじゅ@今はフリー(^^;;;です.

[#3408] Re: sorry for ruby-list trouble — matz@... (Yukihiro Matsumoto) 1997/07/22

まつもと ゆきひろです

[#3414] Re: sorry for ruby-list trouble — keiju@... (石塚圭樹 ) 1997/07/23

けいじゅ@今はフリー(^^;;;です.

[#3420] Re: sorry for ruby-list trouble — matz@... (Yukihiro Matsumoto) 1997/07/23

まつもと ゆきひろです

[#3434] [Q] Thread — keiju@... (Keiju ISHITSUKA)

けいじゅ@今はフリー(^^;;です.

44 messages 1997/07/24
[#3444] Re: [Q] Thread — matz@... (Yukihiro Matsumoto) 1997/07/24

まつもと ゆきひろです

[#3455] Re: [Q] Thread — keiju@... (石塚圭樹 ) 1997/07/24

けいじゅ@今はフリー(^^;;;です.

[#3461] Re: [Q] Thread — matz@... (Yukihiro Matsumoto) 1997/07/25

まつもと ゆきひろです

[#3464] Re: [Q] Thread — keiju@... (石塚圭樹 ) 1997/07/25

けいじゅ@今はフリー(^^;;;です.

[#3483] Re: [Q] Thread — matz@... (Yukihiro Matsumoto) 1997/07/25

まつもと ゆきひろです

[#3528] Re: [Q] Thread — shugo@... (maeda shugo) 1997/07/28

前田です。

[#3537] Re: [Q] Thread — shugo@... (maeda shugo) 1997/07/29

前田です。

[#3542] Re: [Q] Thread — shugo@... (maeda shugo) 1997/07/30

前田です。

[ruby-list:3348] Re: module context and dynamic class define [Re: meta programings]

From: keiju@... (石塚圭樹 )
Date: 1997-07-15 09:22:43 UTC
List: ruby-list #3348
けいじゅ@今はフリー(^^;;;です. 

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 <<---

In This Thread