#erlang
#erlang
Вопрос:
Кажется, во всех книгах erlang говорится, что export_all — плохая практика, но не приводится причина. В конце концов, большинство модулей тратят большую часть своего времени на компиляцию (export_all), потому что постоянное обновление списка модулей для удаления вспомогательных функций является проблемой. Это плохая практика, потому что я должен заботиться о функциях, которые я предоставляю другим разработчикам? Или это плохая практика, потому что количество функций, которые имеет модуль, связано с какими-то затратами на производительность, из-за, возможно, таких вещей, как загрузка горячего кода. Если есть снижение производительности при заполнении модуля множеством функций, насколько это плохо?
Комментарии:
1. потому что легче перепроектировать и без необходимости создавать исполняемый файл большего размера, чем необходимо. никому не нужны имена ваших функций в исполняемом файле, верно?
Ответ №1:
По нескольким причинам:
-
Ясность: легче увидеть, какие функции предназначены для использования вне модуля.
Когда вы вводите вкладку complete в оболочке Erlang, вы получаете список только экспортированных функций и никаких других. Когда вы проводите рефакторинг модуля, вы знаете, какие функции вы можете безопасно переименовывать без внешних пользователей, зависящих от них.
-
Запах кода: вы получаете предупреждения о неиспользуемых функциях.
Поэтому вы избежите мертвого кода.
-
Оптимизация: компилятор может выполнять более агрессивную оптимизацию, зная, что не все функции должны быть экспортированы.
Комментарии:
1. У вас есть источник для резервного копирования заявки на оптимизацию?
2. К сожалению, нет, но я бы предположил, что он сможет использовать встроенные функции, используемые только в одном месте, например, если он знает, что они никогда не будут вызываться извне модуля.
3. Кроме того, это усложняет использование диализатора. @jocull В книге Джо Армстронга «Программирование на Эрланге», 2-е изд., стр. 164, он утверждает, что «компилятор может создавать гораздо лучший код», когда вы экспортируете меньше функций.
Ответ №2:
Хотя я не знаю наверняка, есть ли какие-либо практические последствия использования производительности -compile(export_all). , я сомневаюсь, что они достаточно значительны, чтобы заботиться.
Однако есть преимущество в явном объявлении списка экспорта. Делая это, каждый может разобраться с интерфейсом модуля, просмотрев первую страницу .erl файла. Кроме того, как и во многих других вещах, которые мы склонны записывать, явное объявление интерфейса модуля помогает сохранить его ясность.
С учетом сказанного, когда я начинаю работать над новым модулем Erlang, я всегда печатаю -module(...). -compile(export_all). после того, как интерфейс становится достаточно зрелым, я добавляю explicit -export([...]) , сохраняя параметр export_all compile .
Комментарии:
1. Использование не влияет на производительность
-compile(export_all).. Компилятор обрабатывает все вызовы одинаково, и экспорт выполняется так же, как и при явном экспорте.
Ответ №3:
Наличие определенного списка функций, которые являются внешними, и, следовательно, какие из них являются внутренними, чрезвычайно полезно для всех, кто будет работать над вашим кодом в будущем. Недавно я занимался рефакторингом некоторого старого кода, и использование export_all в большинстве модулей было постоянным источником раздражения.