Methods

So far, in the examples, we have defined only functions using a single method with unlimited argument types. Such functions operate in the same way as in traditional dynamically typed languages. Nevertheless, we almost constantly used multiple dispatching and methods without realizing it: all the standard functions and operators in Julia, such as the aforementioned + function, have many methods that define their behavior for various possible combinations of types and number of arguments.

When defining a function, you can further restrict the types of parameters to which it applies by using the type statement operator ::, presented in the section on composite types:

This function definition applies only to calls in which x and y are type values. Float64:

Her application of it to any other types of arguments will result in MethodError:

As you can see, the arguments must be of type Float64. Other numeric types, such as integers or 32-bit floating-point values, are not automatically converted to 64-bit floating-point, nor are strings parsed as numbers. Since `Float64' is a specific type, and specific types in Julia cannot be subclassed, this definition can only be applied to arguments that are exactly of type `Float64'. However, it is often advisable to write more general methods in which the declared parameter types are abstract.:

This method definition applies to any pair of arguments that are instances of the type Number. They don’t necessarily have to have the same type, as long as they are numeric values. The task of processing heterogeneous numeric types is delegated to arithmetic operations in the expression `2x - y'.

To define a function with multiple methods, it is enough to define the function several times with different number and type of arguments. The first time a method is defined, a function object is created for the function, and subsequent method definitions add new methods to the existing function object. When applying the function, the most specific method definition will be executed, corresponding to the number and types of arguments. Thus, taken together, the two method definitions above define the behavior for f for all pairs of instances of the abstract type Number', but with a different behavior specific to pairs of values. `Float64. If one of the arguments is 64-bit floating point and the other is not, the f(Float64,Float64) method cannot be called, and the more general f(Number,Number) method should be used.:

The definition of '2x + y` is used only in the first case, and the definition of `2x - y' is used in the rest. Automatic conversion or conversion of function arguments is never performed: all conversions in Julia are not something special - they are carried out in a completely explicit way. However, in the chapter Transformation and Promotion shows how the skillful application of sufficiently advanced technology can be indistinguishable from magic. ^[2]

For non-numeric values, as well as for arguments whose number is less than or more than two, the function f remains undefined, and its application will still result in MethodError:

To see which methods exist for a function, enter the function object itself in an interactive session.:

It is clear from this output that f is a function object with two methods. To find out the signatures of these methods, use the function methods:

which shows that f has two methods, one of which takes two arguments of Float64, and the other - arguments of type `Number'. It also specifies the file and line number where the methods were defined: since these methods were defined in the REPL, the obvious line number is `none:1'.

This universal method is less specific than any other possible method definition for a pair of parameter values, so it will only be called for those pairs of arguments to which no other method definition applies.

Note that the type is not specified in the signature of the third method for the arguments x and y. This is an abbreviated way of expressing f(x::Any, y::Any).

Despite its apparent simplicity, multiple dispatch for value types is perhaps the single most powerful and main feature of the Julia language. There are usually dozens of methods used in basic operations.:

Thanks to multiple dispatching, along with a flexible parametric type system in Julia, high-level algorithms can be abstractly expressed, separated from implementation details.

If multiple methods of the same function are created, this is sometimes called "specialization". In this case, the function is specialized by adding additional methods: each new method is another specialization of the function. As shown above, specializations are returned by the methods function.

There is another type of specialization that occurs without programmer intervention: The Julia compiler can automatically specialize the method for the argument types used. Such specializations are not included in the list output by the methods function, so no new methods (Method) are created. However, they can be viewed using tools such as @code_typed.

For example, when creating a method

The mysum' function will receive one new method (possibly the only one) that accepts any pair of the `Real type as input. But if you then execute

Julia compiles mysum twice: once for x::Int, y::Int and once again for x::Float64, y::Float64. The point of double compilation is to improve performance: the methods called for + (and used by mysum) vary depending on the types x and y, and by compiling different specializations in Julia, it becomes possible to search for methods in advance. This allows the program to run much faster, since it does not have to search for methods during execution. Automatic specialization in Julia allows you to write universal algorithms, expecting the compiler to generate efficient, specialized code for each necessary case.

In situations where the number of possible specializations may be unlimited, this default specialization mechanism may not be applied in Julia. For more information, see Keep in mind when specialization in Julia is not done automatically.

A set of function methods can be defined in such a way that there is no unique most specific method applicable to some combinations of arguments.:

Here, the call to g(2.0, 3.0) can be handled either by the g(::Float64, ::Any) method or by the g(::Any,::Float64) method. The order in which the methods are defined does not matter, and neither is more specific than the other. In such cases, Julia issues MethodError, rather than choosing a method arbitrarily. To eliminate the ambiguity of the methods, you need to specify the appropriate method in case of an intersection.:

It is recommended that you first define an unambiguous method, because otherwise there will be ambiguity, albeit temporarily. It will remain until a more specific method is determined.

In more complex cases, a certain design element is required to resolve the ambiguity of the method. This issue is being considered below.

Method definitions may additionally have type parameters defining the signature.:

The first method is used when both arguments have the same specific type, regardless of which type it is, while the second method acts as a universal one, extending to all other cases. So in general, this defines a Boolean function that checks whether two of its arguments have the same type.:

Such definitions correspond to methods whose type signatures are unionAll types (see section unionAll types).

This definition of function behavior through dispatching is quite common — idiomatic — even in Julia. Method type parameters can be used not only as argument types: they can be applied wherever the value is in the function signature or function body. Here is an example where the method type parameter T is used as the type parameter for the parametric type Vector{T} in the method signature:

The type parameter T in this example ensures that the added element x is a subtype of the existing element type of the vector v'. The `where keyword provides a list of these constraints after defining the method signature. It also works for single-line definitions, as shown above, and should appear _ before_ return type declaration, if present, as shown below:

If the type of the element to be added does not match the type of the vector element to which it is being added, an error occurs. MethodError. In the following example, the method type parameter T is used as the return value.:

Just as you can impose subtype restrictions on type parameters in type declarations (see the section Parametric types), you can also impose restrictions on the parameters of method types.

The same_type_numeric function works the same way as the same_type function defined above, but it is defined only for pairs of numbers.

Parametric methods allow the same syntax as the where expressions used to write types (see the section unionAll types). If there is only one parameter, curly braces (in where {T}) can be omitted, but for clarity they often remain the preferred option. Several parameters can be separated by commas, for example, where {T, S<:Real}, or written using a nested where', for example `where S<:Real where T.

When redefining a method or adding new methods, it is important to understand that these changes do not take effect immediately. This is a key factor for Julia’s ability to statically output and compile code for fast execution without the usual techniques and costs associated with JIT. Each new method definition will not be visible to the current runtime environment, including tasks and threads (and any previously defined @generated functions). Let’s start with an example to understand what this means.

Note that in this example, a new definition has been created for newfun, but it cannot be called immediately. The new global object is immediately visible to the tryeval function, so you can write return newfun (without parentheses). But neither you, nor the calling objects, nor the functions they call can call this new method definition.

However, there is an exception: future calls to newfun _ from REPL_ work as expected and can both see and invoke the new definition of the newfun method.

But future calls to tryeval will continue to see the definition of newfun as it was _ before the previous call to REPL_, and therefore before this call to tryeval.

You can try it yourself to see how it works.

The implementation of this behavior is the "world age counter" (hierarchy of method definitions). This monotonously increasing value tracks each method definition operation. The "set of method definitions visible for a given runtime environment" can be described as a single number, or the "age of the world". In addition, it is possible to compare the methods available in the two worlds by simply comparing their sequence number. The example above shows that the "current world" (in which the newfun method exists) is one more than the task-specific "runtime world", which was fixed when the execution of `tryeval' began.

Sometimes this situation needs to be circumvented (for example, in the case of implementing the REPL described above). Fortunately, there is a simple solution: call the function using Base.invokelatest:

Finally, let’s look at some more complex examples where this rule begins to apply. Define the function f(x), which initially has one method:

Run other operations using f(x):

Add a number of new methods to f(x):

Compare the differences between these results:

Although complex dispatch logic is not necessary to improve performance or usability, it can sometimes be the best way to express some algorithms. Here are some common design patterns that sometimes appear in this use case of dispatching.

Function parameters can also be used to limit the number of arguments that can be provided to a function with a variable number of arguments (varargs) (Functions with a variable number of arguments). The notation Vararg' is used to specify such content.{T,N}. For example:

It is more useful to limit methods with a variable number of arguments to a parameter. For example:

it will be called only when the number of indexes corresponds to the dimension of the array.

When it is necessary to limit only the type of arguments provided, Vararg{T} can also be written as T.... For example, f(x::Int...) = x is an abbreviation for f(x::Vararg{Int}) = x.

As briefly mentioned in the chapter Functions, optional arguments are implemented as syntax for multiple method definitions. For example, this definition:

it is converted into the following three methods:

This means that calling f() is equivalent to calling f(1,2)'. In this case, the result will be `5 because f(1,2) calls the first method f above. However, this is not always the case. If we define a fourth method, more specialized for integers:

the result of f()`and `f(1,2)`it will be `-3. In other words, optional arguments are bound to a function, not to any specific method of that function. The method being called depends on the types of optional arguments. If optional arguments are defined according to a global variable, the type of the optional argument may even change during execution.

Named arguments act completely differently from regular positional arguments. In particular, they are not involved in dispatching methods. Methods are dispatched based on positional arguments only, and named arguments are processed after the appropriate method is determined.

Methods are related to types, so any arbitrary Julia object can be made "callable" by adding methods to its type. (Such "callable" objects are sometimes called "functors".)

For example, you can define a type that stores the coefficients of a polynomial, but acts as a function that calculates this polynomial.:

Note that the function is specified by type, not by name. As with regular functions, there is a short syntax. In the body of the function, p will refer to the object that was called. The Polynomial can be used as follows:

This mechanism also determines how type constructors and closures (internal functions that refer to their environment) work in Julia.

Sometimes it is useful to introduce a universal function to which methods have not yet been added. This can be used to separate interface definitions from their implementations. In addition, this option is suitable for documentation purposes or to improve the readability of the code. Here, the syntax is an empty function block without a tuple of arguments.:

Polymorphism of methods in Julia is one of the most powerful features of this language, however, its use can cause difficulties during development. In particular, in more complex hierarchies of methods, there are often ambiguity.

It was noted above that to eliminate ambiguities such as

you can define a method

Most often, this decision will be the right one, but there are circumstances in which thoughtlessly following this advice can lead to the opposite results. In particular, the more methods a universal function has, the higher the possibility of ambiguity. When the hierarchy of methods becomes more complex than in this simple example, it may be necessary to carefully consider alternative strategies.

Next, specific problems and some alternative solutions will be discussed.

You can define methods in local area, for example:

However, local methods should not be defined conditionally or depending on the order of execution, for example:

since it will be unclear which function will eventually be defined. In the future, such a definition of local methods may be considered an error.

In such cases, use anonymous functions.: