Ruby

=begin
互換性の面が懸念されます。

たとえばnested transaction例外を想定しているコード (たとえばtest_thread_safeとか) はどうなるのでしょう。
=end

=begin
デフォルトがブロックするかしないかどっち向きに倒れておくべきかには議論のある所だとは思いますが、いきなり第二引数をなくしてしまうというのはやりすぎではないでしょうか。あなたの嬉しさは他者を排斥する理由としては弱いです。
=end

=begin
Shyouhei Urabe wrote:

デフォルトがブロックするかしないかどっち向きに倒れておくべきかには議論のある所だとは思いますが、いきなり第二引数をなくしてしまうというのはやりすぎではないでしょうか。あなたの嬉しさは他者を排斥する理由としては弱いです。

あまりパッチみてませんけどそれもありましたね。同意します。

せめてthread_safe = trueにしておいて、今の動作と逆転するような感じだと良いですかね?

無視するか動作を逆転させるかどちらかは別として、引数を削るのは賛成しかねます。
=end

=begin
PStoreはRubyのオブジェクトを外部ファイルに格納する為のクラスな訳ですから、あるスレッドがトランザクションを実行中に別のスレッドがトランザクションに入ろうとした場合に、整合性を保つ為に同期する理由はあっても、例外を投げる理由はないのではと考えました。

そこで第2引数を削除したパッチを添付したのですが、確かにいきなり第2引数をなくしてしまうというのはやりすぎだったかも知れません。
それと、私が嬉しいかどうかをこういう場で引き合いに出したのは正しくなかったと思います。

Shota Fukumoriさんの案に賛成します。
ただ、thread_safe = trueとした場合でも、PStore.newに第2引数を与えずにnested transaction例外を想定しているコードには影響してしまいますね。
=end

=begin
sora_hです

考えてみればどうせblockされるわけで必ずブロック内は実行されるわけで、nested transactionはもしダメなら諦める的な感じで捕捉されることを想定しているコードなら
この仕様でも良いかもしれません。transactionが起きているかどうかのコードはin_transactionで調べるべきだと思いますしね。

とりあえず周りの反応次第ですが。その辺の問題が解決できたら入れても良いかもしれないです。

ということで現状は賛成しかね、解決ししだい賛成という立場になります
=end

今となっては僕もどういう状況で困っていたのか忘れてしまったので、他に要望がなければクローズしようと思います。