問題タブ [side-effects]

関数内のループ内に関数があります。内部関数は、データの大きなベクトルを取得してメモリに保存します（グローバル変数として...「S-Plus」のような「R」を使用しています）。ループは、取得するデータの長いリストをループします。外側の関数がプロセスを開始し、取得するデータセットのリストを渡します。

次のデータセットに移動する前に各データセットを格納するように内部関数をプログラムしたため、外部関数のすべての作業はグローバル変数の副作用として発生します...大きな問題はありません。これは、メモリを大量に消費するベクトルのベクトルを収集して返すよりも良いですか、悪いですか? 優れた第 3 のアプローチはありますか?

データ ベクトルをメモリではなくデータベースに格納すると、答えは変わりますか? 理想的には、終了前に処理されたすべての情報を失うことなく、関数を終了できるようにする (またはネットワーク タイムアウトのために失敗する) ようにしたいと考えています。

私は関数型プログラミングを学んでおり、関数型スタイルでいくつかの問題を解決しようとしました。問題を関数に分割しているときに経験したことの 1 つは、2 つのオプションがあるように思われたことです。同様のパラメーター リストを持ついくつかの異なる関数を使用するか、クロージャーとして親関数のバインディングを単純に参照できるネストされた関数を使用します。

関数呼び出しが小さくなり、「感じ」が良くなったように見えたので、最終的には 2 番目のアプローチに行き着きましたが、私の読書では、関数型プログラミングの主要なポイントの 1 つが欠けている可能性があるように思えます。 -効果"? 確かに、これらのネストされた関数は、私が使用していた言語がそれを妨げているため、外部バインディングを変更できませんが、個々の内部関数を見ると、「同じパラメーターが与えられた場合、この関数は同じ結果を返す」とは言えません。親スコープの変数を使用するため...私は正しいですか？

どのような進め方が望ましいでしょうか。

ありがとう！

「getVisibleRegion」と呼ばれるインターフェイス関数のお気に入りのフレームワークの実装がいくつかの UI 機能を無効にしている (そして明らかにそれを復元するのを忘れていた) ことがわかりました。

私はフレームワークにバグを報告しましたが、これにより適切な設計について考えるようになりました: 単なる計算/取得操作を暗示する名前の操作に副作用があるのは、どのような条件の下で正当でしょうか?

実際の詳細に興味のある方へ: プラグインが Eclipse のコードの折りたたみを壊し続け、折りたたみバーが消え、「展開」したり、折りたたまれたコードを表示したりすることができなくなるというバグについての報告がありました。ソース コード ビューアーを表す型を持つ ITextViewer での getVisibleRegion() の呼び出しまでたどり着きました。現在、ITextViewer のドキュメントには、「ITextViewerExtension5 を実装するビューアーは、この契約を履行するために、表示される入力ドキュメントの一部を強制的に変更することができる」と記載されています。ただし、実際の実装では、これを少し自由に取りすぎて、投影 (折り畳み) を永久に無効にし、元に戻すことはありませんでした。

私は、すべてのバイトがカウントされる 8051 のプロジェクトに取り組んでいます。そのため、通常は使用しないいくつかのグローバル変数を使用しています。ポインターを関数に渡す通常の方法では、ここでオーバーヘッドが大きくなりすぎます。

通常の戻り値に加えて、関数の結果を通知するために単一ビット変数 ( Cのコンパイラ固有の拡張機能) を使用する関数がいくつかあります。

テクニックが悪かったので、コードをより明確にする方法はありますか?

どの関数呼び出しにこれらのフラグを設定する副作用があるかをどのように示すべきですか? コメントは十分ですか？API を示すために関数に名前を付ける必要がありますか (準ハンガリー式)? そのような呼び出しをマークするためにマクロを使用する必要があります:

他のアイデアはありますか？

私はその言葉がかなり軽蔑的だと感じます。したがって、ウィキペディアの次の 2 つの文には驚かされます。

命令型プログラミングは、副作用を利用してプログラムを機能させることで知られています。関数型プログラミングは、副作用を最小限に抑えることで知られています。[1]

私はやや数学に偏っているので、後者は素晴らしいと思います。副作用の議論は何ですか？それは制御不能を意味するのか、それとも不確実性を受け入れることを意味するのか? 彼らは良いことですか？

だから私は現在、新しいプログラミング言語に取り組んでいます。並行プログラミングと Haskell から着想を得たこの言語の主な目標の 1 つは、副作用の管理です。多かれ少なかれ、各モジュールは許可する副作用を指定する必要があります。したがって、ゲームを作成する場合、グラフィック モジュールには IO を実行する機能がありません。入力モジュールには、画面に描画する機能がありません。AI モジュールは完全に純粋である必要があります。ゲームのスクリプトとプラグインは、構成ファイルを読み取るために非常に制限された IO のサブセットにアクセスできます。など。

ただし、何が副作用を構成するかは明確ではありません。このテーマについて、自分の言語で検討したい考えや提案を探しています。ここに私の現在の考えがあります。

いくつかの副作用は露骨です。ユーザーのコンソールへの出力であろうと、ミサイルの発射であろうと、ユーザーが所有するファイルの読み取りまたは書き込み、または外部ハードウェアとのやり取りを行うアクションはすべて副作用です。

他のものはより微妙で、これらは私が本当に興味を持っているものです。これらは、乱数の取得、システム時間の取得、スレッドのスリープ、ソフトウェア トランザクション メモリの実装、またはメモリの割り当てなどの非常に基本的なものなどです。

副作用を制御するために構築された他の言語 (Haskell を見てください) とは異なり、私は自分の言語を実用的で実用的なものに設計したいと考えています。副作用に対する制限は、次の 2 つの目的に役立つはずです。

• 関心の分離を支援するため。(1 つのモジュールですべてを実行できるわけではありません)。
• アプリケーション内の各モジュールをサンドボックス化します。(任意のモジュールをプラグインとして使用できます)

それを念頭に置いて、上で述べたように、乱数や睡眠などの「疑似」副作用をどのように処理すればよいでしょうか? 他に何を見逃したでしょうか？リソースとしてのメモリ使用量と時間をどのように管理すればよいでしょうか?

私が常に理解しているように、プログラムの状態 (または IO に関連するもの) への変更は副作用です。変更がグローバル変数で発生するか、メソッドが呼び出されるオブジェクトのプライベート フィールドで発生するかは問題ではありません。したがって、何も返さないすべてのメソッドは、まったく何もしないか、副作用があります。
私の混乱は、私たちの大学のインストラクターの 1 人から来ています (彼はまだ学生なので、まだ全知ではありません;)) セッターには副作用がないと言っていました。

私は最近、関数型プログラミングで遊んでいますが、副作用、なぜそれらを封じ込めるべきかなどのトピックについてはかなり良い治療法があります.OOPが使用されているプロジェクトでは、いくつかの戦略をレイアウトするリソースを探しています副作用および/または状態を最小限に抑えます。

これの良い例は、Web アプリケーションの状態を最小化するための戦略を提供する本RESTful Web Servicesです。他にどんな存在？

別の OOP アナリスト/デザイン パターンの本を探しているのではないことを思い出してください (ただし、適切なカプセル化と疎結合は副作用を回避するのに役立ちます) むしろ、トピック自体が状態/副作用であるリソースを探しています。

いくつかのコンパイルされた回答

• 主に状態を気にする OOP プログラマーは、並行性のためにそうするので、Java Concurrency in Practice を読んでください。[まさに私が探していたもの]
• TDD を使用して、副作用をより目立たせます[私はそれが好きです。例: セットアップが大きくなればなるほど、テストを実行するために必要な状態が増えます = 良い警告です]
• コマンドとクエリの分離 [良いことです。関数の引数を変更することによる、一般的に混乱を招く副作用を防ぎます]
• メソッドが行うことは 1 つだけです。オブジェクトの状態を変更する場合は、わかりやすい名前を使用して単純明快にします。
• オブジェクトを不変にする [私はこれが本当に好き]
• 値をメンバー変数に格納するのではなく、パラメーターとして渡します。[これはリンクしません。それは関数プロトタイプを乱雑にし、Clean Code や他の本によって積極的に落胆させられていますが、状態の問題に役立つことは認めます]
• 値を保存して更新する代わりに、値を再計算します[これもとても気に入っています。私が取り組んでいるアプリでは、パフォーマンスは小さな問題です]
• 同様に、回避できる場合は状態をコピーしないでください。1 つのオブジェクトにそれを保持する責任を持たせ、他の人がそこにアクセスできるようにします。[基本的な OOP 原則、良いアドバイス]

実装し始めているキャッシングのアイデアがあります。

関数をメモ化し、関数シグネチャのハッシュとともに戻り値をVelocityに保存します。PostSharpを使用して、関数を再度呼び出すのではなく、キャッシュをチェックして、戻り値の再水和された表現を返したいと思います。この動作を制御するために属性を使用したいと思います。

残念ながら、これは私の組織の他の開発者にとって危険であることが判明する可能性があります。彼らがパフォーマンスの向上に夢中になり、副作用のあるものも含めて、キャッシュ属性ですべてのメソッドを装飾し始める場合です。関数が副作用を引き起こす可能性があるとメモ化ライブラリが疑った場合、コンパイラの警告を出したいのですが。

CodeDomまたはReflectionを使用して、コードが副作用を引き起こす可能性があることをどのように知ることができますか？

現時点では、副作用を純粋な関数型プログラミング言語に統合する次の方法を認識しています。

• 効果システム
• 続き
• ユニークなタイプ
• モナド

モナドは、これを行うための最も効果的で最も一般的な方法であるとよく言われます。

他にどのような方法がありますか? それらはどのように比較されますか?