14

TwitterのEffective ScalaページでLazyness [sic]に関するセクションを読んでいました.

この目的 [必要に応じて値を計算してキャッシュする] には遅延フィールドを使用しますが、セマンティクスで遅延が必要な場合は遅延を使用しないでください。このような場合、コスト モデルが明示的になり、副作用をより正確に制御できるため、明示的である方が適切です。

なぜ彼らがこの主張をするのか理解できません。セマンティクスによって遅延が必要な場合にキーワードを使用しない方がよいのはなぜですかlazy(つまり、単に最適化として使用するのではなく、プログラムの正確さのために必要であることを意味します)。独自の遅延初期化コードを作成すると、言語に組み込まれたキーワードを使用するよりも遅延が必要であるという事実がどのように明確になるかわかりません! lazyフィールドをスレッドセーフにするために多少の余分なオーバーヘッドがあることは知ってlazyいますが、それが彼らがここで得ていることだとは思いません...

lazyこのガイドラインの使用に関して、私が完全に見逃している隠れた利点がありますか、それともこの提案を無視する方がよいでしょうか?

4

1 に答える 1

6

編集:私はもうアドバイスが何であるかわからないので、Twitterのアドバイスを批評することになると、以下の私のポイントを一粒の塩で取ってください。(しかし、私は以下に私自身のアドバイスをします。)

私もアドバイスに同意しませんが、私は(以前は)彼らのポイントは怠惰が簡単すぎるということだと思います。怠惰な値にアクセスするとパフォーマンスが低下しますが、通常のvalにアクセスする以外のことをしていることに、ユースポイントで気付くことはありません。もちろん、それが怠惰なvalsを非常に便利にする1つのことです。怠惰な動作を切り替えることができ、インターフェースをまったく変更しないでください。しかし、人々がコードをランダムにペッパーするとlazy、重要な領域でのパフォーマンスが低下する可能性があり(遅延評価によって補われる以上ではないと仮定)、初期化の順序を予測するのが難しくなります(特に多くのパフォーマンスを実行している場合は重要です)副作用の)など。

それでも、明示するのは悪いことだと思いますが、懲戒処分を受ける必要があります。文書化または規律のいずれかを当てにすることができない場合は、それを完全に回避する方がよいかもしれません。

于 2012-10-18T17:51:07.813 に答える