Консультации (программирование)

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

Использовать

Практическое использование функций рекомендаций обычно заключается в изменении или ином расширении поведения функций, которые не могут или не должны быть легко изменены или расширены. Например, Emacspeak Emacs -addon широко использует советы: он должен изменить тысячи существующих модулей и функций Emacs так, чтобы он мог производить аудиовыход для слепых, соответствующий визуальному представлению, но было бы невозможно скопировать их все. и переопределить их для вывода звука в дополнение к их обычным выводам; Итак, программисты Emacspeak определяют функции советов, которые выполняются до и после.

Для простого примера Emacs: предположим, что после того, как пользователь исправил слово с ошибкой с помощью модуля Emacs ispell , он захотел повторно проверить орфографию всего буфера. ispell-word не предлагает такой функции, даже если исправленное слово часто появляется в буфере. Пользователь может найти определение ispell-word, скопировать его в свои личные файлы Emacs и добавить туда желаемую функциональность, но это утомительно и, что еще хуже, хрупко (пользовательская версия теперь не синхронизирована с базовой реализацией Emacs, если она вообще работает без дальнейшего рефакторинга). То, что хочет пользователь, довольно просто — просто запустить другую команду в любой момент. ispell-word бежит. Воспользовавшись советами, это можно сделать так просто:

 (advice-add #'ispell-word
  :after #'flyspell-buffer)

Хотя этот пример очевидно тривиален, сила совета, особенно по сравнению с аналогичными средствами, такими как декораторы Python и аннотации Java , заключается в том, что рекомендуемые функции/методы не только не должны быть спроектированы так, чтобы принимать советы, но и сами советы не обязательно должны быть предназначены для использования в качестве советов — это просто обычные функции. Доступность оценки на протяжении всего жизненного цикла фрагмента кода (см. промежуточный код рекомендации ) в Lisp позволяет автоматически встраивать в любой другой код различными способами. Любому фрагменту кода можно посоветовать выполнить любые другие вычисления до, после, вокруг или вместо его первоначального определения.

Читабельность

Советы могут внести путаницу, поскольку совет, примененный к функции, неочевиден для пользователя, который отслеживает исходное определение функции, чтобы узнать о ней. В таких случаях совет действует почти как COMEFROM , средство шутки, добавленное к INTERCAL, чтобы подделать спагеттификацию , сопутствующую широкому использованию GOTO . Однако на практике подобные проблемы возникают редко. Разработчики и сопровождающие Lisp-пакетов и модулей никогда не прибегают к советам, поскольку рекомендации по функциям не дают никаких преимуществ, если их исходные определения можно свободно переписать для включения желаемых функций. Совет полезен только тем, что он позволяет последующим пользователям впоследствии изменять поведение по умолчанию таким образом, чтобы не требовать распространения таких изменений в определение источника базовой реализации.

Реализации

Форма советов была частью C с классами в конце 1970-х и начале 1980-х годов, а именно функции, называемые call и return определенные в классе, которые вызывались до (соответственно, после) функций-членов класса. Однако они были исключены из C++ .

Советы являются частью Common Lisp Object System (CLOS), поскольку :before, :after, и :around методы, которые объединены с основным методом в разделе «стандартная комбинация методов».

Реализации Common Lisp предоставляют функциональность рекомендаций (в дополнение к стандартной комбинации методов для CLOS) в виде расширений. Лиспворкс поддерживает функции консультирования, макросы и методы CLOS.

В EmacsLisp добавлен код, связанный с советами, в версии 19.28 1994 года.

История

Следующее взято из обсуждения в списке рассылки aosd-discuss . Паскаль Костанца внес следующее:

Термин «совет» восходит к термину «советование» , введенному Уорреном Тейтельманом в его докторской диссертации в 1966 году. Вот цитата из главы 3 его диссертации:

Консультирование является основным нововведением в модели и в системе ПИЛОТ. Консультирование заключается во вставке новых процедур в любую или во все точки входа или выхода в конкретную процедуру (или класс процедур). Вставленные процедуры называются «консультационными процедурами» или просто «советами».

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

Основное преимущество консультирования состоит в том, что пользователю не нужно беспокоиться ни о деталях реальных изменений в его программе, ни о внутреннем представлении совета. Он может рассматривать процедуру, которую ему рекомендуют, как единицу, отдельный блок, и вносить в нее изменения, не заботясь о деталях этого блока. Это можно противопоставить редактированию, при котором программист должен знать внутреннюю структуру процедуры.

«Консультирование» проникло в BBN Lisp , а затем в Xerox PARC компании Interlisp .

Он также нашел применение во Flavors , первом объектно-ориентированном расширении Lisp, разработанном в Массачусетском технологическом институте . Они были отнесены к понятию комбинации методов.

Поскольку комбинация методов и макросы тесно связаны, также интересно отметить, что первая макросистема была описана в 1963 году, за три года до защиты докторской диссертации Уоррена Тейтельмана.

См. также

• Декоратор функций (относительно Python )
• Аспектно-ориентированная разработка программного обеспечения#Консультационные органы

Примечания

Грегор Кичалес комментирует вышеизложенное следующим образом:

Внешние ссылки

• Кандидатская диссертация Тейтельмана «ПИЛОТ: шаг к симбиозу человека и компьютера» (AITR-221)
• Справочное руководство Interlisp от 1974 года.
• «Происхождение совета»