Стоит ли когда-нибудь использовать списки ассоциаций вместо записей?

Question

Могут ли опытные программисты на Erlang рекомендовать списки ассоциаций поверх записей?

В одном случае два (или более) узла на разных машинах обмениваются сообщениями. Мы хотим иметь возможность обновлять программное обеспечение на каждой машине независимо. Некоторые обновления могут включать добавление поля к одному (или нескольким) из отправляемых сообщений. Похоже, использование записи в качестве сообщения означало бы, что вам всегда нужно будет выполнить обновление на обеих машинах на этапе блокировки, чтобы дополнительное поле не заставляло получателя игнорировать запись. Принимая во внимание, что если бы вы использовали что-то вроде списка ассоциаций (у которого все еще есть «подобный записи» API), еще не обновленный получатель все равно получит сообщение успешно и просто проигнорирует новое поле. Я понимаю, что это не всегда желаемое поведение, но часто это так. Кроме того, предположим, что сообщения довольно малы, поэтому время поиска не имеет значения.

Предполагая, что вышеизложенное имеет некоторый смысл, у меня есть следующие дополнительные вопросы:

• Существует ли стандартная (или широко используемая) библиотека для списков? Какой-то банальный поиск в Google ничего не дал.
• Есть ли другие случаи, когда вы бы использовали список ассоциаций (или что-то подобное)?

Answer 1

Для небольшого количества ключей вы можете использовать списки aka proplists , для больших вы должны использовать dict В обоих случаях самым большим недостатком является то, что вы не можете использовать сопоставление с шаблоном так, как это используется для записей. Существует также штраф за скорость, но в большинстве случаев он не имеет значения.

Answer 2

У вас есть в основном три варианта:

1. Использовать записи
2. Использовать списки ассоциаций (проплисты)
3. Используйте комбинацию

Я использую записи, где вероятность их изменения очень мала. Таким образом я получаю сопоставление с образцом и ускоряю то, что хочу.

Я использую проплисты, где мне нужна функциональность, подобная хеш-таблице. Я получаю гибкость за счет сопоставления с образцом и скорости.

И иногда я использую оба. Запись с одним полем, которая является проплистом. Таким образом, я могу сопоставлять паттерны на его части и при этом иметь гибкость там, где мне это нужно.

Все три варианта имеют разные компромиссы, поэтому вам просто нужно оценить ваши конкретные потребности и сделать выбор. Может потребоваться некоторое прототипирование и игра, чтобы выяснить, какие компромиссы имеют смысл и какие функции вам абсолютно необходимы.

Answer 3

Обратите внимание, что списки: keysearch / 3 в значительной степени "assq".