問題タブ [mutability]

私は最近、IList ではなく厳密に型指定された配列を返すことを好む理由を誰かに尋ねていました。私はずっと、インターフェイスに対するプログラミングが、プロジェクトの存続期間が長い場合に最も柔軟で最善の方法であると考えていました。それで、彼がこう答えたとき、私は奇妙に感じました。

私たちは通常、可変型よりも不変型を好みます。配列は不変です。IList ではありません。

私はこの声明を理解しているかどうか完全には確信が持てません。誰でもこれを明確にするのを助けることができますか?

皆さんが提供できる助けをありがとう。

同様の操作（つまり、多くのマップを1つのマップにマージします。この質問を参照）について、Scalaのimmutable.Mapとmutable.Mapのパフォーマンス特性を比較したいと思いました。可変マップと不変マップの両方で同様の実装のように見えるものがあります（以下を参照）。

テストとして、1,000,000個の単一アイテムのMap [Int、Int]を含むリストを生成し、このリストをテスト対象の関数に渡しました。十分なメモリがあれば、結果は驚くべきものではありませんでした。mutable.Mapの場合は約1200ミリ秒、immutable.Mapの場合は約1800ミリ秒、mutable.Mapを使用した命令型実装の場合は約750ミリ秒です。それについてもコメントしてください。

少し驚いたのは、おそらく私が少し太っていたためです。IntelliJ8.1のデフォルトの実行構成では、両方の可変実装がOutOfMemoryErrorにヒットしましたが、不変コレクションはヒットしませんでした。不変テストは最後まで実行されましたが、非常にゆっくりと実行されました。約28秒かかります。最大JVMメモリを増やしたところ（約200MB、しきい値がどこにあるかわからない）、上記の結果が得られました。

とにかく、これが私が本当に知りたいことです：

なぜ可変の実装はメモリを使い果たしますが、不変の実装はそうではありませんか？ 不変バージョンでは、可変実装が実行する前にガベージコレクターを実行してメモリを解放できると思いますが、これらのガベージコレクションはすべて、不変の低メモリ実行の遅さを説明していますが、より詳細な説明が必要ですそれより。

以下の実装。（注：これらが可能な限り最良の実装であるとは言いません。遠慮なく改善を提案してください。）

Pretty Big を使用した Dr.Scheme のこのコードの何が問題になっていますか? 過去に同様のことを問題なく行ったことを覚えているようです。

次のエラーが返されます。

set!: not an identifier in: (Frame-variables res)

(set! (Frame-variables res) ... )もちろん、リストが実際に変更されないことを除いて、その部分を省略しても問題なく動作します。2番目のものは認識し(Frame-varialbes res)ますが、最初のものは認識しませんか? set!またはその文脈での取引は何ですか？

Frameリストであるvariablesフィールドで呼び出された構造体があることを認識していただければ幸いです。

「値の制限」は、実際には高次の関数型プログラミングがないことを意味しますか?

HOP を少し実行しようとするたびに、VR エラーが発生するという問題があります。例：

それがVRの特定の実装の問題なのか、型システムに突然変異を含まない可変型推論言語で解決策がない一般的な問題なのかを知りたいです。

私は以前にこの種の問題を抱えていましたが、満足のいく答えが得られませんでした。

NSMutableArray である「郡」と呼ばれるプロパティを持つビューコントローラーがあります。ナビゲーション画面をドリルダウンして、地理的検索のために郡を選択するビューに移動します。したがって、検索ページは「郡の選択」ページにドリルダウンします。

NSMutableArray *counties2 番目のコントローラーをナビゲーション スタックにプッシュするときに、2 番目のコントローラーに渡します。以下に示すように、実際には、最初のコントローラーの「郡」へのポインターを使用して、2 番目のコントローラーの「selectedCounties」プロパティ (これも NSMutableArray) を設定しました。

しかし、そこに行くとaddObject、次のようになります。

これが私のコードです：

SearchViewController.h:

SearchViewController.m で:

SearchLocationsViewController.h:

SearchLocationsViewController.m で (ここでのポイントは、テーブルの各要素がアクティブであるか、選択された郡のリストに含まれていないかを切り替えていることです):

私たちはそこで死ぬ[self.selectedCounties addObject....。

今、自分[self.selectedCounties class]で NSLog を実行すると、NSCFArray であることがわかります。

これはどのように起こりますか？クラスバンドルについては理解していますが（またはとにかく理解していると思います）、これは明示的に特定のタイプであり、ある時点でサブクラス化してすべてを殺す方法で失われています。なぜそれが起こるのか、私にはまったく理解できません。

ビジターがレシーバーの状態を変更できるようにすることは一般的に受け入れられますか、それとも代わりにコマンドパターンにする必要がありますか？

最近 iPhone の開発を行っていた私は、オブジェクトの可変性に関して、iPhone SDK で多く使用されている興味深いデザイン パターンに気付きました。

不変のクラスを定義し、そこNSFooから可変の子孫を派生させるのが典型的なアプローチのようNSMutableFooです。一般に、NSFooクラスはデータ メンバー、ゲッター、および読み取り専用操作を定義し、派生したものNSMutableFooはセッターと変更操作に追加されます。

C++ に慣れてきた私は、これが C++ で同じコードを書く場合とはまったく逆のように思われることに気付きました。確かにそのアプローチを取ることもできますが、より簡潔なアプローチは、単一のFooクラスを作成し、getter と読み取り専用操作をconst関数としてマークし、可変操作と setter を同じクラスに実装することだと私には思えます。Foo const*その後、変更可能なクラスになりますが、タイプFoo const&などはすべて実質的に不変の同等物です。

私の質問は、状況に対する私の見解は理にかなっていますか? Objective-C の動作が異なる理由は理解できますが、C++ の 2 クラス アプローチには、私が見逃した利点はありますか? それとも私はポイントを完全に見逃していますか？

あまり深刻な質問ではありません - 何よりも私自身の好奇心のためです.

部分的に変更可能なクラスでは、変更可能なフィールドと不変のフィールドを混在させるか、それらをカプセル化する新しいクラス (または複数のクラス) を作成する方がよいでしょうか? 私が話していることのC＃の例を次に示します。

以下は、フィールドに可変性が混在する実装です。

そして、別の可変性を持つもの:

および分離可変性の実装:

個人的には後者のスタイルを支持します。私の経験では、同時実行シナリオでの状態操作から生じるバグはデバッグが困難です。並行性がプログラムの標準になるにつれて、可変性をローカライズすることがデバッグ作業を削減するための重要な要素になるようです。2 番目の例では、状態が操作されている場所を見つけるために、クラスの実装全体を調べる必要はありません。の可変性全体SeparatedMutabilityBedroomが にローカライズされていRoomColorます。

どう思いますか？考慮事項をいくつか忘れていませんか？

f＃の変数についての私の表面的な理解は、変数を「可変」であると宣言することと「ref」変数を使用することの両方が本質的に同じことを行うことを示唆しています。これらは両方とも、同じ根本的な問題に対処するための異なる方法です。つまり、IOモナドに頼る必要なしに、関数型言語での可変性の制限された構造化された許容値です。技術的な違いがあるということは、私の理解によって「抽象化」されています。

1. この場合、クロージャは可変変数をキャプチャできないのに、refインスタンスをキャプチャできるのはなぜですか？
2. より一般的には、この違いを可能にする2つの形式の技術的な違いは何ですか？
3. 1つだけではなく2つの可変性ショートカットを導入するという言語設計の観点からの目的は何ですか？

これがマルチパートナーの場合は申し訳ありませんが、それらはすべて関連しているようです。

プロセスを実行する前に、かなりの量の構成データを構築する必要があるプロジェクトがあります。構成段階では、データを変更可能にすると非常に便利です。ただし、構成が完了したら、そのデータの不変ビューを機能プロセスに渡したいと思います。そのプロセスは、その計算の多くで構成の不変性に依存するためです (たとえば、インターフェイスを使用して読み取り専用ビューを公開する可能な解決策を思いつきましたが、このタイプのアプローチで問題が発生したことがあるかどうか、または方法に関する他の推奨事項があるかどうかを知りたいです。この問題を解決します。

私が現在使用しているパターンの一例：

編集

Lippert 氏と cdhowie からの入力に基づいて、次のようにまとめました (簡略化するためにいくつかのプロパティを削除しました)。

FreezableList<T>ご想像のとおり、 は のフリーズ可能な実装ですIList<T>。これにより、複雑さが増しますが、断熱効果が得られます。