Методы

До сих пор в примерах мы определяли только функции с помощью одного метода, имеющего неограниченные типы аргументов. Такие функции действуют так же, как и в традиционных языках с динамической типизацией. Тем не менее мы почти постоянно использовали множественную диспетчеризацию и методы, не осознавая этого: все стандартные функции и операторы в Julia, такие как вышеупомянутая функция +, имеют множество методов, определяющих их поведение при различных возможных сочетаниях типов и количества аргументов.

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

Это определение функции применимо только к вызовам, в которых x и y являются значениями типа Float64:

Ее применение его к любым другим типам аргументов приведет к MethodError:

Как видно, аргументы должны иметь тип Float64. Другие числовые типы, такие как целые числа или 32-разрядные значения с плавающей запятой, не преобразуются автоматически в 64-разрядные с плавающей запятой, равно как и строки не анализируются как числа. Поскольку Float64 является конкретным типом, а конкретные типы в Julia не могут быть разделены на подклассы, такое определение может быть применено только к аргументам, которые точно имеют тип Float64. Однако часто бывает целесообразно писать более общие методы, в которых объявленные типы параметров являются абстрактными:

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

Чтобы определить функцию с несколькими методами, достаточно определить функцию несколько раз с разным количеством и типом аргументов. При первом определении метода для функции создается объект функции, а при последующих определениях метода к существующему объекту функции добавляются новые методы. При применении функции будет выполняться наиболее конкретное определение метода, соответствующее количеству и типам аргументов. Таким образом, взятые вместе два определения метода, приведенные выше, определяют поведение для f для всех пар экземпляров абстрактного типа Number, но с другим поведением, характерным для пар значений Float64. Если один из аргументов является 64-разрядным с плавающей запятой, а другой — нет, метод f(Float64,Float64) не может быть вызван, и следует использовать более общий метод f(Number,Number):

Определение 2x + y используется только в первом случае, а определение 2x - y — в остальных. Автоматическое приведение или преобразование аргументов функций никогда не выполняется: все преобразования в Julia не являются чем-то особенным — они осуществляются совершенно явным образом. Однако в главе Преобразование и продвижение показано, как умелое применение достаточно продвинутой технологии может быть неотличимо от магии. ^[2]

Для нечисловых значений, а также для аргументов, количество которых меньше или больше двух, функция f остается неопределенной, и ее применение все равно приведет к MethodError:

Чтобы увидеть, какие методы существуют для функции, введите сам объект функции в интерактивном сеансе:

Из этих выходных данных ясно, что f является объектом функции с двумя методами. Чтобы узнать сигнатуры этих методов, используйте функцию methods:

которая показывает, что f имеет два метода, один из которых принимает два аргумента Float64, а другой — аргументы типа Number. Она также указывает файл и номер строки, где были определены методы: поскольку эти методы были определены в REPL, выводится очевидный номер строки none:1.

При отсутствии объявления типа с помощью :: типом параметра метода по умолчанию является Any, что означает, что он не имеет ограничений, поскольку все значения в Julia являются экземплярами абстрактного типа Any. Таким образом, можно определить универсальный метод для f следующим образом:

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

Обратите внимание, что в сигнатуре третьего метода для аргументов x и y тип не указан. Это сокращенный способ выражения f(x::Any, y::Any).

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

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

Если создается несколько методов одной функции, иногда это называют «специализацией». В данном случае функция специализируется путем добавления дополнительных методов: каждый новый метод — это еще одна специализация функции. Как показано выше, специализации возвращаются функцией methods.

Есть еще один вид специализации, который происходит без вмешательства программиста: Компилятор Julia может автоматически специализировать метод для используемых типов аргументов. Такие специализации не включаются в список, выводимый функцией methods, так при этом новые методы (Method) не создаются. Однако их можно просматривать с помощью таких средств, как @code_typed.

Например, при создании метода

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

Julia скомпилирует mysum дважды: один раз для x::Int, y::Int и еще раз для x::Float64, y::Float64. Смысл двойной компиляции заключается в повышении производительности: методы, вызываемые для + (и используемые mysum), различаются в зависимости от типов x и y, и благодаря компиляции разных специализаций в Julia становится возможен заблаговременный поиск методов. Это позволяет программе выполняться гораздо быстрее, так как во время выполнения ей не приходится заниматься поиском методов. Автоматическая специализация в Julia позволяет писать универсальные алгоритмы, ожидая, что компилятор сгенерирует эффективный, специализированный код для каждого необходимого случая.

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

Набор методов функций можно определить таким образом, чтобы не было уникального наиболее конкретного метода, применимого к некоторым сочетаниям аргументов:

Здесь вызов g(2.0, 3.0) может быть обработан либо методом g(Float64, Any), либо методом g(Any, Float64), и ни один из них не является более конкретным, чем другой. В таких случаях Julia выдает MethodError, а не выбирает метод произвольно. Чтобы исключить неоднозначность методов, нужно указать соответствующий метод на случай пересечения:

Рекомендуется сначала определить однозначный метод, поскольку в противном случае будет, пусть и временно, присутствовать двусмысленность. Она останется до тех пор, пока не будет определен более конкретный метод.

В более сложных случаях для разрешения неоднозначности метода требуется определенный элемент проектирования. Этот вопрос рассматривается ниже.

Определения методов могут дополнительно иметь параметры типа, определяющие сигнатуру:

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

Такие определения соответствуют методам, сигнатуры типов которых являются типами UnionAll (см. раздел Типы UnionAll).

Подобное определение поведения функции через диспетчеризацию является довольно распространенным — идиоматическим — даже в Julia. Параметры типов методов могут использоваться не только в качестве типов аргументов: они могут применяться везде, где значение будет находиться в сигнатуре функции или теле функции. Вот пример, где параметр типа метода T используется в качестве параметра типа для параметрического типа Vector{T} в сигнатуре метода:

Как видно, тип добавляемого элемента должен совпадать с типом элемента вектора, к которому он добавляется, иначе возникает MethodError. В следующем примере параметр типа метода T используется в качестве возвращаемого значения:

Подобно тому как можно накладывать ограничения подтипа на параметры типа в объявлениях типов (см. раздел Параметрические типы), можно также накладывать ограничения на параметры типов методов.

Функция same_type_numeric работает так же, как и определенная выше функция same_type, но она определена только для пар чисел.

Параметрические методы допускают тот же синтаксис, что и выражения where, используемые для записи типов (см. раздел Типы UnionAll). Если параметр только один, фигурные скобки (в where {T}) можно опустить, но для ясности они часто остаются предпочтительным вариантом. Несколько параметров могут быть разделены запятыми, например where {T, S<:Real}, или записаны с помощью вложенного where, например where S<:Real where T.

При переопределении метода или добавлении новых методов важно понимать, что эти изменения вступают в силу не сразу. Это ключевой фактор для возможности Julia статически выводить и компилировать код для быстрого выполнения без обычных приемов и затрат, связанных с JIT. Каждое новое определение метода не будет видно текущей среде выполнения, включая задачи и потоки (и любые ранее определенные функции @generated). Начнем с примера, чтобы понять, что это значит.

Обратите внимание, что в этом примере было создано новое определение для newfun, но оно не может быть вызвано немедленно. Новый глобальный объект сразу виден функции tryeval, поэтому можно написать return newfun (без круглых скобок). Но вызвать это новое определение метода не можете ни вы, ни вызывающие объекты, ни вызываемые ими функции.

Однако существует исключение: будущие вызовы newfun из REPL работают ожидаемым образом и могут как видеть, так и вызывать новое определение метода newfun.

Но будущие вызовы tryeval будут продолжать видеть определение newfun таким, каким оно было при предыдущем обращении к REPL, а значит, и до этого вызова tryeval.

Вы можете попробовать сами, чтобы увидеть, как это работает.

Реализацией этого поведения является «счетчик возраста мира» (иерархия определения методов). Это монотонно возрастающее значение отслеживает каждую операцию определения метода. «Набор определений методов, видимых для данной среды выполнения» можно описать как одно число, или «возраст мира». Кроме того, можно сравнивать методы, доступные в двух мирах, просто сравнивая их порядковый номер. В примере выше видно, что «текущий мир» (в котором существует метод newfun), на единицу больше, чем локальный для задачи «мир среды выполнения», который был зафиксирован, когда началось выполнение tryeval.

Иногда эту ситуацию необходимо обойти (например, в случае реализации описанного выше REPL). К счастью, есть простое решение: вызвать функцию с помощью Base.invokelatest:

Наконец, рассмотрим несколько более сложных примеров, где начинает действовать это правило. Определите функцию f(x), которая изначально имеет один метод:

Запустите другие операции, использующие f(x):

Добавьте ряд новых методов в f(x):

Сравните отличия этих результатов:

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

Параметры функции можно также использовать для ограничения количества аргументов, которые могут быть предоставлены функции с переменным количеством аргументов (varargs) (Функции с переменным количеством аргументов). Для указания такого содержимого используется нотация Vararg{T,N}. Пример:

Более полезным является ограничение методов с переменным количеством аргументов параметром. Пример:

будет вызываться только тогда, когда число indices соответствует размерности массива.

Когда нужно ограничить только тип предоставляемых аргументов, Vararg{T} можно также записать как T.... Например, f(x::Int...) = x является сокращением для f(x::Vararg{Int}) = x.

Как кратко упоминалось в главе Функции, необязательные аргументы реализуются как синтаксис для множественных определений методов. Например, это определение:

преобразуется в следующие три метода:

Это означает, что вызов f() эквивалентен вызову f(1,2). В этом случае результатом будет 5, поскольку f(1,2) вызывает первый метод f выше. Однако так бывает не всегда. Если определить четвертый метод, более специализированный для целых чисел:

результатом f() и f(1,2) будет -3. Другими словами, необязательные аргументы привязаны к функции, а не к какому-либо конкретному методу этой функции. Вызываемый метод зависит от типов необязательных аргументов зависит. Если необязательные аргументы определены в соответствии с глобальной переменной, тип необязательного аргумента даже может измениться во время выполнения.

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

Методы связаны с типами, поэтому любой произвольный объект Julia можно сделать «вызываемым», добавив методы к его типу. (Такие «вызываемые» объекты иногда называют «функторами».)

Например, можно определить тип, который хранит коэффициенты полинома, но действует как функция, вычисляющая этот полином:

Обратите внимание, что функция указана по типу, а не по имени. Как и в случае с обычными функциями, существует краткая форма синтаксиса. В теле функции p будет ссылаться на объект, который был вызван. Polynomial можно использовать следующим образом:

Этот механизм также определяет то, каким образом в Julia работают конструкторы типов и замыкания (внутренние функции, которые ссылаются на свое окружение).

Иногда полезно ввести универсальную функцию, в которую еще не добавлены методы. Это можно использовать для отделения определений интерфейсов от их реализаций. Кроме того, такой вариант подходит для целей документирования или улучшения читаемости кода. Здесь синтаксисом является пустой блок function без кортежа аргументов:

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

Выше было отмечено, что для устранения неоднозначностей, таких как

можно определить метод

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

Далее будут рассматриваться конкретные проблемы и некоторые альтернативные способы их решения.

Вы можете определять методы в локальной области, например:

Однако локальные методы не следует определять условным образом или в зависимости от порядка выполнения, например:

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

В таких случаях используйте анонимные функции: