問題タブ [immutability]

私の知る限り、Delphi では文字列は不変です。あなたがそうするなら、私はそれが意味することをちょっと理解しています：

最初の文字列が破棄され、新しい文字列 "Hello World" への参照が取得されます。

しかし、コード内の異なる場所に同じ文字列がある場合はどうなるでしょうか?

いくつかの変数を識別するために文字列ハッシュが割り当てられているため、たとえば、「変更」はその変更のプロパティのハッシュ値によって識別されます。そうすれば、平等の「変更」を簡単にチェックできます。

現在、各ハッシュは個別に計算されます (すべてのプロパティが考慮されるわけではないため、一部の値が異なっていてもインスタンスを分離することができます)。

問題は、Delphi がこれらの文字列をどのように処理するかです。ハッシュを同じ 10 バイト長の文字列に分離するために計算すると、何が得られますか? 10 バイトの 2 つのメモリ ブロックまたは同じメモリ ブロックへの 2 つの参照?

明確化:変更は、データベースから読み取られたいくつかのプロパティによって構成され、個々のスレッドによって生成されます。TChange クラスには、文字列の結果の一部の値 (すべてではない) に基づいてハッシュを計算する GetHash メソッドがあります。現在、他のスレッドは変更を受け取り、それを以前に処理された変更と比較して、同じ (論理的な) 変更を処理しないようにする必要があります。したがって、ハッシュと、それらには別個のインスタンスがあるため、2 つの異なる文字列が計算されます。文字列から 128 ビット ハッシュのようなものに変更することが実際の改善になるのか、それとも時間を無駄にするだけなのかを判断しようとしています。

編集：DelphiのバージョンはDelphi 7.0です

.net フレームワーク 4 には BigInteger クラスが含まれるようです。ただし、不変になるかどうかはわかりません。それが良いことなのかどうかも、私には判断できないようです。

不変性には、特に big-int のような「値のような」ものに対して、多くの利点があります。一方、PowerMod のような高コストの操作をできるだけ高速に行うには、基本的な操作を効率的に行う必要があります。インプレース追加は、不変追加よりも高速になります。私は現在、ライブラリ クラスのより良い選択として不変性に傾いています (String を考えてください)。

それが不変になるかどうかは誰にも分かりますか？不変であるべきだと思いますか？

追加の属性を持つ文字列が必要です。たとえば、赤または緑で印刷するかどうかを考えてみましょう。

Subclassing(str) は不変であるため、機能しません。値はわかりますが、煩わしい場合があります。

多重継承は役に立ちますか? 私はそれを使用したことはありません。

オブジェクトのみを継承し、self.value=str を使用すると、すべての文字列性メッセージ (ストリップなど) を自分で実装する必要があります。

または、Ruby の missing_method のように転送する方法はありますか?

インスタンスによってインデックス付けされたクラスレベルの辞書を使用して色を保存するとうまくいくと思います。あまりにも醜いです？

「不変関数」または「不変メソッド」とは、同じ引数を与えても結果が決して変わらない関数を意味します。

不変関数の事前計算された値をキャッシュしたい場合、より一般的または冗長でない解決策を誰かが知っているかどうか知りたいです。

簡単な例で私が何を意味するかを説明しましょう。

注:
- C++ のソリューションとして C++ というタグも追加しました。これも興味があります
- 関数は「不変」または「トランザクション内で不変」と定義できるため、「不変関数」の概念はデータベース開発者にとって一般的です (これは、クエリのパフォーマンスを向上させる良い方法です)。

前もって感謝します

サブクラス化しようとしてstrいますが、不変性のためにいくつかの問題があります。

のような新しい機能を必要としない継承されたメソッドの場合、 （の代わりに）derived.lower()型のオブジェクトを返す簡単なpythonicの方法はありますか？または、私が行ったように、各str.method（）を手動でオーバーライドすることに固執していますか？DerivedClassstrderived.upper()

編集：

私は最近関数型プログラミングについて学んでいます (具体的には Haskell ですが、Lisp と Erlang のチュートリアルも経験しています)。概念は非常に啓発的であることがわかりましたが、「副作用なし」の概念の実際的な側面はまだわかりません. それの実際的な利点は何ですか？私は関数型の考え方で考えようとしていますが、簡単な方法で状態を保存する機能がなければ、非常に複雑に見える状況がいくつかあります (私は Haskell のモナドを「簡単」とは考えていません)。

Haskell (または他の純粋関数型言語) を深く学び続ける価値はありますか? 関数型またはステートレス プログラミングは、実際に手続き型よりも生産的ですか? Haskell や別の関数型言語を今後も使用し続ける可能性は高いですか、それとも理解するためだけに学習する必要がありますか?

私は生産性よりもパフォーマンスを重視しています。だから私は主に、手続き型/オブジェクト指向/その他よりも関数型言語の方が生産性が高いかどうかを尋ねています。

ディクショナリを含む C# のクラスがあります。このディクショナリを作成し、それを含むクラスが存在する限り、このディクショナリから追加、編集、または削除されないようにしたいと考えています。

readonly は、後でアイテムを追加できることをテストして確認したら、実際には役に立ちません。たとえば、次の例を作成しました。

Add メソッドが機能しないようにします。できればコンパイルすらしないようにしたいです。助言がありますか？

実際、多くの人に公開されるコードなので心配です。そのため、Add メソッドを非表示にしても、誰かがキーを追加したり、別のキーを削除したりするメソッドを「無邪気に」作成する可能性があります。私は人々に、決して辞書を変更してはならないことを知ってもらいたいと思っています。私がconst変数を持っているのと同じように。

ドメイン モデルには不変の値オブジェクトがたくさんあります。その一例が、緯度、経度、高さによって定義される位置です。

位置の編集を許可する明白な方法は、getterとsetterを持つ ViewModel と、検証済みの不変の位置インスタンスを抽出する ToPosition() メソッドを構築することです。この解決策は問題ありませんが、多くの重複コード、特に XAML が発生します。

問題の値オブジェクトは、通常、X、Y、Z およびいくつかの補助要素のバリアントである 3 ～ 5 つのプロパティで構成されます。これを考慮して、さまざまな可能性を処理するために 3 つの ViewModel を作成することを検討しました。各 ViewModel は、各プロパティの値のプロパティと、各ラベル (「Latitude」など) に表示する説明を公開する必要があります。

さらに進むと、N 個のプロパティを処理し、リフレクションを使用してすべてを接続できる 1 つの一般的な ViewModel に単純化できるようです。プロパティ グリッドのようなものですが、不変オブジェクト用です。プロパティ グリッドの 1 つの問題は、次のようなラベルとテキスト ボックスを使用できるように、外観を変更できるようにすることです。

または、次のような DataGrid に配置します。

だから私の質問は：

この問題を解決するエレガントな方法を思いつきますか? これを行うライブラリや、同様の記事はありますか?

私は主に探しています：

• コードの重複を最小限に抑える
• 新しい値のオブジェクト タイプを簡単に追加できます
• ある種の検証で拡張可能

struct私は頻繁にs が不変であるべきだと読んでいます - それらは定義上そうではありませんか?

int不変だと思いますか？

大丈夫そうです - 新しい を取得し、intに割り当て直しiます。これはどうですか？

わかりました、ショートカットと考えることができます。

はどうstruct Pointですか？

これは本当にポイントを変更し(1, 2)ますか? Point.Offset()新しいポイントを返すことで、次のショートカットと考えるべきではないでしょうか。

この考えの背景はこれです - アイデンティティのない値の型はどのようにして変更可能になるのでしょうか? 変更されたかどうかを判断するには、少なくとも 2 回確認する必要があります。しかし、アイデンティティなしでどうやってこれを行うことができますか?

refパラメータとボクシングを考慮して、これについての推論を複雑にしたくありません。p = p.Offset(3, 4);が不変性を表現するよりもはるかに優れていることも認識してp.Offset(3, 4);います。しかし、疑問が残ります - 定義上、値型は不変ではないのでしょうか?

アップデート

変数またはフィールドの可変性と、変数の値の可変性という、少なくとも 2 つの概念が関係していると思います。

この例では、可変フィールドと不変フィールドを使用する必要があります。値型フィールドには値全体が含まれるため、不変フィールドに格納される値型も不変である必要があります。私はまだ結果に非常に驚いています.readonlyフィールドが変更されないままになるとは思っていませんでした.

変数 (定数を除く) は常に変更可能であるため、値型の変更可能性に対する制限はありません。

答えはそれほど単純ではないようですので、質問を言い換えます。

以下を考える。

の完全なバージョンFooと使用例 (refパラメーターとボックス化が含まれる場合があります) を提供していただけますか?

と

私が作成しているアプリケーションでは、不変である可能性が高い多くの基本型を作成する必要があります。しかし、可変型と不変型が並列アプリケーションでどのように比較されるのか疑問に思っています。

変更可能なオブジェクトでロックを使用できますよね? 並列アプリケーションで不変型に使用される他の手法と比べてどうですか?

少なくとも、不変型のロックを使用することから離れていますよね?