Цель протоколов в Clojure - эффективное решение проблемы выражения.
Итак, в чем проблема выражения? Это относится к основной проблеме расширяемости: наши программы манипулируют типами данных с помощью операций. По мере развития наших программ нам необходимо расширять их за счет новых типов данных и новых операций. В частности, мы хотим иметь возможность добавлять новые операции, которые работают с существующими типами данных, и мы хотим добавить новые типы данных, которые работают с существующими операциями. И мы хотим, чтобы это было истинное расширение , т.е. мы не хотим изменять существующийпрограмма, мы хотим уважать существующие абстракции, мы хотим, чтобы наши расширения были отдельными модулями, в отдельных пространствах имен, отдельно компилировались, отдельно развертывались, отдельно проверялся тип. Мы хотим, чтобы они были безопасными по типу. [Примечание: не все из них имеют смысл на всех языках. Но, например, цель сделать их безопасными по типу имеет смысл даже в таком языке, как Clojure. То, что мы не можем статически проверить безопасность типов, не означает, что мы хотим, чтобы наш код прерывался случайным образом, верно?]
Проблема выражения состоит в том, как на самом деле обеспечить такую расширяемость на языке?
Оказывается, что для типичных наивных реализаций процедурного и / или функционального программирования очень легко добавлять новые операции (процедуры, функции), но очень сложно добавлять новые типы данных, поскольку в основном операции работают с типами данных с использованием некоторых вид случая дискриминации ( switch, case, шаблон соответствия) и вам нужно добавить новые случаи к ним, то есть изменить существующий код:
func print(node):
case node of:
AddOperator => print(node.left) + '+' + print(node.right)
NotOperator => '!' + print(node)
func eval(node):
case node of:
AddOperator => eval(node.left) + eval(node.right)
NotOperator => !eval(node)
Теперь, если вы хотите добавить новую операцию, скажем, проверку типов, это просто, но если вы хотите добавить новый тип узла, вы должны изменить все существующие выражения сопоставления с образцом во всех операциях.
А для типичного наивного объектно-ориентированного объекта у вас есть прямо противоположная проблема: легко добавить новые типы данных, которые работают с существующими операциями (либо путем наследования, либо переопределения их), но сложно добавить новые операции, поскольку это в основном означает изменение существующие классы / объекты.
class AddOperator(left: Node, right: Node) < Node:
meth print:
left.print + '+' + right.print
meth eval
left.eval + right.eval
class NotOperator(expr: Node) < Node:
meth print:
'!' + expr.print
meth eval
!expr.eval
Здесь добавить новый тип узла легко, потому что вы либо наследуете, либо переопределяете, либо реализируете все необходимые операции, но добавить новую операцию сложно, потому что вам нужно добавить ее либо ко всем конечным классам, либо к базовому классу, изменяя таким образом существующие код.
В нескольких языках есть несколько конструкций для решения проблемы выражения: Haskell имеет классы типов, Scala имеет неявные аргументы, Racket имеет единицы измерения, Go имеет интерфейсы, CLOS и Clojure имеют мультиметоды. Есть также «решения», которые пытаются решить эту проблему, но так или иначе терпят неудачу: интерфейсы и методы расширения в C # и Java, Monkeypatching в Ruby, Python, ECMAScript.
Обратите внимание, что в Clojure фактически уже есть механизм для решения проблемы выражения: мультиметоды. Проблема, с которой объектно ориентированный объект связан с EP, заключается в том, что они объединяют операции и типы вместе. В мультиметодах они разделены. Проблема FP заключается в том, что они объединяют операцию и различение регистра. Опять же, с мультиметодами они разделены.
Итак, давайте сравним протоколы с мультиметодами, поскольку оба делают одно и то же. Или, другими словами: зачем протоколы, если у нас уже есть мультиметоды?
Главное, что протоколы предлагают по сравнению с мультиметодами, - это группировка: вы можете сгруппировать несколько функций вместе и сказать: «эти 3 функции вместе образуют протокол Foo». Вы не можете этого сделать с мультиметодами, они всегда работают сами по себе. Например, вы могли бы заявить , что Stackпротокол состоит из обоего а pushи popфункции тусовки .
Так почему бы просто не добавить возможность группировать мультиметоды вместе? Есть чисто прагматическая причина, и именно поэтому я использовал слово «эффективный» во вводном предложении: производительность.
Clojure - это размещаемый язык. Т.е. он специально разработан для работы на платформе другого языка. И оказывается, что практически любая платформа, на которой вы хотели бы запустить Clojure (JVM, CLI, ECMAScript, Objective-C), имеет специализированную высокопроизводительную поддержку для диспетчеризации исключительно по типу первого аргумента. Clojure Мультиметоды OTOH отправки на произвольные свойства из всех аргументов .
Таким образом, протоколы ограничивают отправку только по первому аргументу и только по его типу (или, как особый случай nil).
Это не ограничение идеи протоколов как таковых, это прагматичный выбор для получения доступа к оптимизации производительности базовой платформы. В частности, это означает, что протоколы имеют тривиальное сопоставление с интерфейсами JVM / CLI, что делает их очень быстрыми. Фактически, достаточно быстро, чтобы иметь возможность переписать те части Clojure, которые в настоящее время написаны на Java или C #, в самом Clojure.
В Clojure фактически уже были протоколы, начиная с версии 1.0: например Seq, это протокол. Но до версии 1.2 вы не могли писать протоколы на Clojure, вам приходилось писать их на основном языке.