[#3234] sample of TkFont class — NAGAI Hidetoshi <nagai@...>

永井@知能.九工大です.

52 messages 1998/07/08
[#3241] Re: sample of TkFont class — NAGAI Hidetoshi <nagai@...> 1998/07/09

永井@知能.九工大です.

[#3290] Re: sample of TkFont class — NAGAI Hidetoshi <nagai@...> 1998/07/15

永井@知能.九工大です.

[#3291] Re: sample of TkFont class — matz@... (Yukihiro Matsumoto) 1998/07/15

まつもと ゆきひろです

[#3307] Re: sample of TkFont class — NAGAI Hidetoshi <nagai@...> 1998/07/16

永井@知能.九工大です.

[#3309] Re: sample of TkFont class — matz@... (Yukihiro Matsumoto) 1998/07/16

まつもと ゆきひろです

[#3319] Re: sample of TkFont class — NAGAI Hidetoshi <nagai@...> 1998/07/16

永井@知能.九工大です.

[#3321] Re: sample of TkFont class — matz@... (Yukihiro Matsumoto) 1998/07/16

まつもと ゆきひろです

[#3324] Re: sample of TkFont class — NAGAI Hidetoshi <nagai@...> 1998/07/16

永井@知能.九工大です.

[#3367] Re: sample of TkFont class — Tadayoshi Funaba <tadf@...> 1998/07/22

ふなばです。

[#3369] Re: sample of TkFont class — ttate@... 1998/07/22

立石@JAISTです。

[#3370] Re: sample of TkFont class — Tadayoshi Funaba <tadf@...> 1998/07/22

ふなばです。

[#3371] Re: sample of TkFont class — ttate@... 1998/07/23

立石@JAISTです。

[#3292] exprimental release 1.1b9_31 (hopefully final) — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

20 messages 1998/07/15
[#3293] Re: exprimental release 1.1b9_31 (hopefully final) — Takahiro Maebashi <maebashi@...> 1998/07/15

前橋です。

[#3294] Re: exprimental release 1.1b9_31 (hopefully final) — matz@... (Yukihiro Matsumoto) 1998/07/15

まつもと ゆきひろです

[#3295] Re: exprimental release 1.1b9_31 (hopefully final) — Takahiro Maebashi <maebashi@...> 1998/07/15

前橋です。

[ruby-dev:3183] Re: experimental release 1.1b9_28

From: "YANAGAWA Kazuhisa" <kjana@...>
Date: 1998-07-01 14:21:46 UTC
List: ruby-dev #3183
in [ruby-dev:3182] Re: experimental release 1.1b9_28
Tadayoshi Funaba <tadf@kt.rim.or.jp> writes:

> >  ってやって,後は bar をつかう,というのと変わらない,と.....「値を
> >  使うときには一定のやり方をするだけで,式が高々一回だけ評価されること
> >  が保証される」という点ではあの delay は十分優れているのですが.
>
> 僕は違うんじゃないかと信じてますけど :-)

  はい「一定のやり方でアクセスすれば式が高々一回しか評価されない」とい
  うことが異なっているわけです.で,どうせならもっと透過に,ということ
  でああなった,と.

> たぶん、気のせいでしょう。変数に関連づけられるという解釈はないんじゃな
> いでしょうか。force がなくてもかまわない流儀ってのはあるみたいですね。
> そういう処理系をつかっていたので、そう思ったってことはないでしょうか。

  もっといろんな物と混ざってる可能性があります.なんといっても scheme
  をプログラムに使ったことは一度も無い (^^; 多分 future 関係の何かだと
  思います.でも,なんだろう?

> ええ、でも、force もあったほうがよくないですか。
>
> というのは、 たとえば、配列を生成する Promise を渡されたとき、それをい
> きなり多重代入で分解しようとしてもできませんよね。

  そういえばそんなのもありましたね.あれ書いてたときにはすっかり忘れて
  ました (^^;

> そうすると、そのオブジクトがなんだったのか考えなくちゃいけません。
> Promise + [] とかすればいいんですけど、それだったら force したほうが
> よさそうに思うんです。forceもできる、という選択はないですか。

  force は無いけど __getobj__ があります.これが 3 の意味.

  # touch っていうメソッドを作ったら,__getobj__ と同じになったので,
  # きっちゃいました.

===========================================================================
  柳川和久 @ 東大阪市 . 大阪府
  kjana@os.xaxon.ne.jp                                       July 1, 1998
Penny wise, pound foolish.



In This Thread

Prev Next