丸山＠東工大です。

At Wed, 23 Feb 2000 06:35:11 +0900,
nobu.nakada / nifty.ne.jp wrote:
> 
> なかだです。
> 
> At Wed, 23 Feb 2000 03:01:25 +0900,
> 中村暁史 Nakamura Akifumi <BXQ04723 / nifty.ne.jp> wrote:
> > > 現在のHash#update(other)では、HashオブジェクトselfにHashオブジェクト
> > > otherをマージする機能を提供していますが、このマージの際に、selfとother
> > > の両方に同じキーのエントリがある場合、otherの方の値で上書きすることに
> > > なっています。この動作を変更し、同じキーのエントリがあった場合には
> > > updateに与えられたブロックでどちらの値を選択するか決められるようにしま
> > > せんか？
> > 
> > それって、updateとは違う名前にするほうが
> > すっきりするなーと思ったです。
> > 選択といっても、selfのほうの値を選択する時ってのはつまり
> > update「しない」ことになるわけですよね。
> > updateって一律全部updateしちゃうからupdateっていう
> > (日本語になってないぞ俺)ようなきがします。
> 
>   納得。

うーん、イメージしているupdateの使い方がちょっと違っていたかもしれませ
ん。私としては、分散管理されている簡単なデータベースみたいなものを考え
ていて、その分散されたデータの同期をとる時に使うことを想定していました。

＊イメージ＊
・ host Aとhost Bで、それぞれがHashで表現されたデータベースを管理してい
   て、通常は、それぞれが独立にデータを追加更新している。
・ Hashの値の方は更新された時刻を含むようなオブジェクトになっている。
・ host Aとhost Bは、時々お互いのデータベースを参照して、同期をとる。
   同じキーに対応するデータは更新時刻が新しいものを選ぶようにマージす
   る。←この部分がupdateという気分。

つまり、selfとotherで、全ての要素についてselfよりotherの方が古いという
ことを期待しないというのは、それほど不自然ではないんじゃないかと……。

> > > otherをマージする機能を提供していますが、このマージの際に、selfとother
「マージする」という言葉を出したのは、マニュアルのupdateの説明がそうなっ
ていたからです。

>   そしたら merge でしょう、やっぱり。

mergeの方が良いかもしれませんね。

--
丸山冬彦
東京工業大学 情報理工学研究科 数理計算科学専攻 松岡研究室
mailto:fuyuhik8 / is.titech.ac.jp
http://matsu-www.is.titech.ac.jp/%7emaruyama/