日々の破片

_ ブロックとオブジェクト

VB2005便利：Usingステートメントで簡単……を読んでちょっと考えた。

僕は、usingマンセーなのだが、その一方でIDisposable/Dispose/using に関してという議論での、Closeとの違い、インターフェイスの公開、共有の3点についての吉松さんの指摘も正しそうに思える。もっとも3番目の論点については、共有する場合にはusingなんて使えないねというのが答えだし、その結果1についてはだから両方必要じゃんとなる（共有不可ならCloseは不要。ただし長く利用するものはブロックには持てないのでその場合はやはりCloseが必要（Disposeのエイリアスとして）という感じかな。Open／Close、Create／Disposeとかで生成時のメソッド名の好みに依存するだけだったりして）のだが。2番目は公開すりゃいいと思ってるから隠している実装というものの設計思想についてはこちらが知りたいな、という程度でしかない。だからusingが提供されていて、共有するのじゃなければがんがん使うのが良いと思う。それによって確実にリソースの解放漏れが減るからだ。ちなみに、この議論は途中で一般化してしまってusingの存在が消えているが、単純にusingで囲ってコンパイルエラーになればusingを使わずにCloseを呼べば済むだけの話に見える。usingのためのインターフェイスじゃん。

で、VB.NET2005にはusingが……というのとの対比で、J2SE 1.5のConcurrencyユーティリティのLockを考える。

synchronziedステートメントの美点はそれがブロックだという点そのものだ。つまり、例外で飛ぼうがなんだろうが確実にアンロックされるという点だ。これが、C++で同期プリミティブを扱うという話になれば確実にアンロックされないパスが生じてたわけだから（ということも無いか）、ブロック化されるのは非常に良いことに思える。

ところが、Concurrencyユーティリティで、まるで同期プリミティブのようにロックしたままアンロックせずにどこかに行ける機能が提供されることになった。なんだかなぁ、という印象を持たざるを得ない。もっとも、アノテーションなんかと同じで、使う局面が絞られてるわけなんだが。で、この絞られるが、IDisposableが使えない局面（共有とか長くオープンしたまま保持するとか）と同じようなものかな、と思ったのだった。

実際には、とにかく2種類あったほうが良い。

#ほとんどの場合
File.open('foo', 'r') do |f|
  s = f.read
  p s
end
#でも稀に
f = File.open('foo', 'r')
s = f.read
p s
f.close