11

私はイミュータブル コレクション (主に Clojure で、それらを「永続的なデータ構造」と呼んでいます) を使用することにややハマっており、iOS および OS X のいくつかのコンテキストでこの方法でプログラミングできるようになりたいと思っています。

これが役立つ主な例は、変更されたコピーを作成することによって辞書を「変更」できるようにすることであり、変更を次のように体系化しようとするのではなく、変更リスナーが古い値と新しい値の違いを照会できるようにすることです。プロパティ変更イベント。不変データ構造は、並行プログラミングのゲームチェンジャーでもあります。ロックは必要ありません。

NSArrayはい、現在は不変のインスタンスとインスタンスを使用してこれを行うことができますがNSDictionary、コレクションがますます大きくなったり、頻繁に変更を加えたりするため、それらをコピーして「変更された」バージョンを作成するのはますます非効率的になります。大きなデータ構造への小さな変更とてつもない量の仕事を伴う。

Objective-C で不変データ プログラミングを有効にする方法を探しています。これがどのように見えるかを明確にし、それが提供する利点のいくつかを明確にするために、この SO の質問で参照されている Phil Bagwell による研究は非常に関連性があります。

4

2 に答える 2

3

Ridiculous Fish のこの記事を参照してください (AppKit チームのエンジニアであり、Fish シェルの作成者でもある Cory Doras によって書かれたと思います):

配列: 私たちの配列ではありません。http://ridiculousfish.com/blog/posts/array.html

あなたはすでにあなたの質問に答えています：

はい、不変の NSArray および NSDictionary インスタンスを使用してこれを行うことができます...

Cocoa フレームワークの優れた点は、特にデータ構造に関する単純さです。アイデアは、あなたではなく、舞台裏のコードが構造を実装する方法を決定する必要があるということです。実際には、配列と辞書 (または、他の言語から来た場合はマップ) の 2 つの "タイプ" のデータ構造だけが必要です。もちろん、多くの「タイプ」の実装が必要ですが、実際に必要なのはデータにアクセスする 2 つの方法だけです。より多くの方法が必要な場合は、カスタム クラスとコンポジションの出番です。

効率の懸念については、心配しないでください。Cory (Ridiculous Fish) の記事によると、内部的には、Apple はすでに効率性に関するあなたの条件を満たしていることがわかります。Ian Murray がコメントで指摘したように、これは単なるポインタです。すべてが参照カウントされ、必要な場合にのみコピーされます。NSArray または NSDictionary を「コピー」または「mutableCopy」すると、基になるデータが実際にはコピーされない可能性が最も高くなります。これを実装する方法については、Rob Pike の Go 言語に関する記事 ( http://blog.golang.org/slices ) を参照してください。Cocoa が同様のパターンを踏襲していることはほぼ確実です。

さらに、Objective-C の「ブロック」の出現により、 LISP バリアント (Clojure など)の関数型スタイルでプログラミングすることがますます実現可能になりました。実際、私はこれを強くお勧めし、この道を歩み続けることをお勧めします。正しく行えば、より安定した、よりクリーンなコードにつながる可能性があります。

于 2013-10-15T16:40:15.517 に答える
2

ここに近道はないと思います。

おっしゃる通り、Clojure の永続的なデータ構造は、Cocoa が提供する不変のコレクション クラスとはまったく異なります。

Clojure の永続的なデータ構造を Obj-C から使用したい場合、唯一の方法は、それらを Objective-C で再実装することです。私の理解では、これらの多くは岡崎の著書Purely Functional Data StructuresとPhil Bagwellの論文で説明されています。

この他の回答にはいくつかのリンクがあります: Clojureのセットの背後にあるデータ構造は何ですか? .

于 2013-12-31T19:00:53.053 に答える