Есть ли недостатки в передаче записи Erlang в качестве аргумента функции? - PullRequest
3 голосов
/ 22 февраля 2010

Есть ли недостатки в передаче записи Erlang в качестве аргумента функции?

Ответы [ 3 ]

5 голосов
/ 22 февраля 2010

Недостатков нет, если только функция вызывающей стороны и вызываемая функция не были скомпилированы с разными «версиями» записи.

3 голосов
/ 24 февраля 2010

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

Это кажется мне не эрлангичным (вы никогда не делаете это нормально, если вы не используете упомянутые функции из stdlib), создает странные взаимозависимости и сложнее использовать из оболочки (я бы не стал я не могу понять, как загружать и использовать записи из оболочки - я обычно просто "обманываю", создавая кортеж вручную ...)

Кроме того, обработка записей немного отличается от того, что вы обычно делаете, поскольку их ключи по умолчанию принимают атом «неопределенный» в качестве значения, что противоречит тому, как вы обычно делаете это с проплистами, например (значение, которое не было не устанавливается), это может вызвать путаницу у людей, которые обычно не работают с записями.

Итак, в общем, я бы предпочел проплист или что-то подобное, если только у меня нет очень веской причины использовать запись. Однако я обычно использую записи для внутреннего состояния, например, gen_server или gen_fsm; Это несколько проще обновить таким образом.

2 голосов
/ 23 февраля 2010

Я думаю, что самым большим недостатком является то, что это не идиоматично. Вы когда-нибудь видели API, который требовал от вас создания записи и ее передачи?

Зачем вам делать что-то, что будет казаться чуждым любому программисту на эрланге? Существует соглашение, уже используемое для необязательных именованных аргументов функций. Придумывать еще один путь без веской причины бессмысленно.

...