The first situation where behavior inheritance could be useful is when interest lies only in a subset of all possible instances of an already existent type. For example, let’s assume that we want to create a new composite type Simplex, which shall contain all points on the -dimensional simplex . Thereby, the simplex is defined as the set of -dimensional points with individual entries being positive and summing up to one:

Clearly, is a subset of . And, for points of we already have a quite simple and suitable type in Julia: Array{Float64, 1}. However, representing the simplex in Julia, we would like to have a type that corresponds to only a subset of all instances of Array{Float64, 1}. This way, we can achieve more robust coding, since users will not be able to manually break the summation constraint too easily. Also, the creation of a new composite type allows overloading function definitions. We hence could create a method plot(x::Simplex) which suits the specific characteristics of the subset of . On the other hand, however, any instance of Simplex still represents an element of , and hence ideally should behave as such in Julia as well. Any methods generally working on Array{Float64, 1} should also be working for instances of Simplex. In contrast to some object oriented languages, Julia does allow subtypes only for abstract types, and not for composite types. Hence, even though any mathematical operation on arbitrary points in also holds simultaneously for points of as well, methods of Array{Float64, 1} will not automatically apply for instances of type Simplex.

A naive way to fix this would be through definition of an appropriate conversion method, allowing to re-interpret instances of Simplex as instances of Array{Float64, 1}. This way, an already existing method of Array{Float64, 1} could be generally expressed for type Simplex:

function f(x::Simplex)
    xAsArray = convert(Array{Float64, 1}, x)
    return f(xAsArray)
end

Even more efficiently, one could incorporate a tight relation to Array{Float64, 1} into type Simplex from scratch up, defining Simplex such that it contains only one field, which is of type Array{Float64, 1}.

type Simplex
    points::Array{Float64, n}
end

This way, the conversion step becomes unnecessary, as methods only need to be delegated to the respective field of Simplex:

f(x::Simplex) = f(x.points)

Hence, we now already have a quite good starting point for inheritance of behavior. Instances of type Simplex, when plugged into the function, return the same value as if the -dimensional simplex point was simply represented as Array{Float64, 1}. Nevertheless, as we will see further on, a lot of intricacies are yet to come. But, before we get there, we first take a look at a second situation where inheritance of behavior might be desired.

In the first case we where implementing a true subset relation, with . Here, we will take a given type and try to extend it with some new attribute. For example, let’s assume that we had to deal with numeric time series data that does not have any missing values. Of course, the data could be suitably stored and processed as instance of the very general type DataFrame. Time information would simply be stored in the first column, with values of the observations in the subsequent columns. However, data might be better stored as instances of a type that is more tailored to the specific characteristics of the data. For example, as the data values itself are numeric (except for the time column), they permit statistical operations like, for example, deriving mean, minimum and maximum values. Separating numeric observations from dates, code becomes more robust, as we are able to better distinguish between functions applying to the numerical part of the data and functions applying to the dates information.

For illustration, let’s look at two distinct ways of translating time series data into Julia data types. In the first case, we simply treat the data as true subset of type DataFrame, although in a newly created type TimeSeriesDf. This way, we still can overload functions and create methods that take into account the specific characteristics of the data. For example, a method plot(ts::TimeSeriesDf) would show date labels on the x-axis. Hence, we define:

type TimeSeriesDf
    vals::DataFrame
end

The problem is, that it becomes more tedious to separate dates and numeric data. For example, a method mean(ts::TimeSeriesDf) now might be implemented as

mean(ts::TimeSeriesDf) = mean(ts.vals[:, 2:end])

In contrast, we could also define a type TimeSeries that has two fields, where the first field deals with dates, and the second field contains numeric observations only.

type TimeSeries
    dates::Array{Date{ISOCalendar}, 1}
    vals::DataFrame
end

The distinction between dates and numeric data hence becomes more hard-coded into the data type. Here, a mean method would require no additional indexing:

mean(ts::TimeSeries) = mean(ts.vals)

In a way, instances of type TimeSeries are no true subtypes of type DataFrame anymore, as they are characterized through an additional dates field. It extends a simple DataFrame with an additional array of dates. Ideally, such a type should inherit behavior of both individual field types, making its application a naturally extension to already existing types. For example, adding a scalar value should take into account field vals only:

+(ts::TimeSeries, x::Numeric) = +(ts.vals, x)

This way, one can achieve a very nice and intuitive way of handling time series data. For more information, simply take a look at package TimeData, where you can see the benefits of type inheritance and type extension in a more elaborate use case.

In my opinion, these are the two most common cases where one would like to have a new composite type behaving like some already existent type. In both cases, the key lies in the delegation of functions to certain fields of the composite type.

We already have seen examples of functions that are easily delegated to the respective field of the new type. For functions like size() this makes perfect sense, and the method definition becomes:

size(nd::NumDf) = size(nd.vals)

However, not all the time this kind of perfect delegation is how we want methods to behave. Simply delegating all methods this way, we would end up permanently escaping our own data type. For example, simply delegating method exp(nd::NumDf) would indeed evaluate the exponential function on each individual entry. However, it would return these values as an instance of type DataFrame, as does method exp(df::DataFrame):

exp(nd::NumDf) = exp(nd.vals)
nd = NumDf(DataFrame(rand(3, 2)));
nd2 = exp(nd);

typeof(nd)
typeof(nd2)

NumDf (constructor with 1 method)
DataFrame (constructor with 22 methods)

Given that the returned values still meet the required constraints, we would like the method to return the resulting values as type NumDf again. Otherwise there would be no persistence in our data representation, as we would end up with type DataFrame sooner or later anyways.

Hence, we need to write some methods such that the original type of our data will remain unaffected. Methods get delegated to methods of the respective emulated type, but the returned value needs to be transferred back to the inheriting type. Therefore, we simply need to hand over the result to the constructor at the end:

function exp(nd::NumDf)
    valsDf = exp(nd.vals)
    return NumDf(valsDf)
end

We hence need to state more precisely what “inheriting behavior” should mean for any given method: should it return exactly the same output as the emulated type, or should it wrap up the resulting values at the end, in order to return an instance of the same type as the caller type? Both alternatives require slightly different code. Also, this distinction will become relevant in the course of meta-programming for more general cases comprising multiple functions and multiple new types.

The next complication arises for functions with multiple method signatures. Due to multiple dispatch, functions may well have multiple methods defined that need to be delegated. For example, you can examine the size of DataFrames with two different methods size():

size(df::AbstractDataFrame)
size(df::AbstractDataFrame, i::Integer)

In principle, each of both methods could just be delegated for itself.

size(tn::NumDf) = size(tn.vals)
size(tn::NumDf, i::Integer) = size(tn.vals, i)

This, of course, seems to be redundant, as it is quite cumbersome to delegate each method individually. Hence, one might be tempted to tackle both methods in one assignment, making use of variable function arguments:

size(tn::NumDf, args...) = size(tn.vals, args...)

Although this seems quite reasonable, one still needs to be very careful with this approach, since it could easily lead to method ambiguities. For example, let’s take a look at function .== for DataFrames. Amongst others, there exist the following methods:

.==(a::DataFrame,b::NAtype)
.==(a::DataFrame,b::DataFrame)
.==(a::DataFrame,b::Union(Number,String))

Using variable function arguments, the delegation would be implemented as:

.==(x::NumDf, args...) = .==(x.vals, args...)

This, however, will lead to the following warning:

Warning: New definition 
    .==(NumDf,Any) at none:1
is ambiguous with: 
    .==(Any,AbstractArray{T,N}) at bitarray.jl:1450.
To fix, define 
    .==(NumDf,AbstractArray{T,N})
before the new definition.

Hence, there are two methods that possibly could be called for (NumDf,AbstractArray{T,N}), and Julia will kind of randomly pick one of them.

Although in this case both methods .== would most likely lead to the same result when called with .==(NumDf,AbstractArray{T,N}) anyways, it is considered poor style to simply ignore these warnings.

Furthermore, the ambiguity is not a side effect of the variable function argument only, but it also appears with the following method definition:

.==(x::NumDf, y::Any) = .==(x.vals, y)

In my opinion, it is better to refrain from extensive method delegations with args... or Any whenever possible. Even if your own code worked, excessive use of such extensive delegations could still impose problems for other people that want to build on your code.

Nevertheless, this does not mean that you have to type any individual method definition by itself! For example, a really large part of methods of DataFrames comes with the exact same method signatures:

f(b::NAtype,a::DataFrame)
f(a::DataFrame,b::NAtype)
f(a::DataFrame,b::DataFrame)
f(a::DataFrame,b::Union(String,Number))
f(b::Union(String,Number),a::DataFrame)

Using macros and metaprogramming, one can easily define all functions with equal method signatures simultaneously in one rush.

Using the instructions above, you’re now able to emulate behavior of a different type in almost all cases. Still, however, there are some special cases where you will most likely need to find your own solution.