[ruby-list:1938] Re: [Dist] Mutex module

けいじゅ＠SHLジャパンです. 

In [ruby-list :01935 ] the message: "[ruby-list:1935] Re: [Dist] Mutex
module ", on Jan/29 15:14(JST) [e-mail] (Yukihiro Matsumoto)
writes:

>|削除した要素に対して何か処理を行ないたいとすると, リターン値がなんであ
>|るか条件判断が必要になりますよね...

>|hash.delete(key, if_none_block) if_exist_block
>
>うーん，なんでそんないちどにいろんなことをしようとするんです
>かね．Smalltalkerの性ですかね．これじゃぜんぜんdeleteじゃな
>いですよね(存在判定も同時にしている)．

うーん. うーん. まあ, ごちゃごちゃになっていることは認めましょう. 

begin...endの方はそれほどひどくないかなと...

>rubyが遅いから? すみませんねえ．
>
>if hash[key]
>  value = hash.delete(key)
>  あった場合の処理
>end
>後処理

>ではいけない理由がなにかあるんですね．

ハッシュを2回引きたくない... でも, そういえば

if !(value = hash.delete(key)).nil?   # 原さんのメイル対応(^^;;
  あった場合の処理
end
後処理

でも良いような... 

# nil?の反対演算しはないですよね?

イテレータに拘り過ぎて気がつかなかった(*^^;;;

>|>|2. Hash#[], key?...
>
>昔ですか? 全てのkeyと全てのvalueから計算していました．eql?が
>導入される前のまま変更していなかったんですね．

うーん. うーん.

>以下の通りです．このうちいくつかは同一性に戻した方が良いかも
>知れません(Array,Struct??)．
>
>  Array
>  Bignum
>  Float
>  (Hash)
>  String
>  Struct
>  Time

すくなくともArrayは戻した方が良いでしょう. それで嬉しい人はあまりいな
いと思いますし... Structはどうかなあ... メンバが固定だからこのままでも
良いような, 同一性の方が良いような...

>厳密にはそうかも知れませんが，それがないのがruby風だと感じて
>います．実際困ることはないと信じていますし．
>
># なぜって同一性は処理系によって保証されていないので，それに
># 依存するようなプログラムを書くためのハッシュは要らないはず

え? 保証されていない?? あるオブジェクトのidが変わることがあるのですか???
そんなことはないですよね? どういう意味だろう?

>|a. メソッド名の競合はinclude/extendした側で解消する.
>|b. モジュール側でそのような仕組みを用意しておく.
>
>現状では辛かろうがなんだろうが，基本的にaです．bを実現するた
>めの仕組みがないからです．さて，いまのところbのような仕組み
>は思い付かないのですが，良いアイディアがありますか?

そこまで, 深い意味があったわけでもないんです.

module Mutex_m
  def mu_lock
     ...
  end

  def object_extended
    if respond_to?(lock)
      alias lock mu_lock
    end
  end
end

こんな感じであまり競合しそうもない名前をデフォルトで用意しておいて, も
し競合しなかったらaliasするという漢字を考えていました.

# includeした時には何かhook関数が呼ばれるんでしたっけ?

__
..........................................石塚 圭樹＠SHLジャパン(株)...
------------->アドレス変わりました!! e-mail: [e-mail] <----