レコードの代わりに関連付けリストを使用することをお勧めしますか？

Question

Erlangの経験豊富なプログラマーがレコードにassociation listsをお勧めしますか？

異なるマシン上の2つ（またはそれ以上）のノードがメッセージを交換している場合があります。各マシンのソフトウェアを個別にアップグレードしたいと考えています。一部のアップグレードでは、送信されるメッセージの1つ（または複数）にフィールドを追加することがあります。レコードをメッセージとして使用すると、余分なフィールドでレシーバーがレコードを無視しないように、常に両方のマシンでアップグレードを行う必要があります。アソシエーションリスト（まだ「レコードライク」APIを持っています）のようなものを使用した場合、まだアップグレードされていない受信者はメッセージを正常に受信し、新しいフィールドを無視します。私はこれがではなく、常にであることを理解していますが、はよくです。また、メッセージがかなり小さいので、参照時間が重要ではないと仮定します。上記と仮定

は、いくつかの理にかなって、私は次の追加の質問があります。

• を連想リストのための標準的な（あるいは広く使われている）のライブラリはありますか？いくつかの些細なグーグルでは何も出てこなかった。
• アソシエーションリスト（またはそのようなもの）を使用する他のケースはありますか？

Answer 1

あなたは基本的に3つの選択肢があります。

1. 使用レコード
それを変更する可能性が非常に低い
2. 使用連想リスト（proplistを）

私はレコードを使用

使用コンビネーション。そうすれば、私はパターンマッチングを得て、私が望むようにスピードアップします。

私はハッシュテーブルのような機能が必要なプロプリストを使用します。パターンマッチングとスピードを犠牲にして柔軟性を得ることができます。

時々私は両方を使用します。 1つのフィールドがプロプリストであるレコード。そうすれば、私はそれの一部に一致をパターン化することができ、それでも必要なところで柔軟性を得ることができます。

3つの選択肢にはそれぞれ異なるトレードオフがあるため、基本的に特定のニーズを評価して選択する必要があります。どのトレードオフが理にかなっているか、どんな機能が必要なのかを理解するためには、プロトタイピングや遊びが必要かもしれません。

Answer 2

リスト：keysearch/3はかなり "assq"です。

Answer 3

キーの量が少ない場合は、proplistsのリストを使用することができます。dictを使用してください。どちらの場合でも最大の欠点は、レコードに使用されるようにパターンマッチを使用できないことです。スピード違反もありますが、ほとんどの場合は無関係です。