Abstract types and inheritance in Julia

Question

Suppose I define a function on an abstract type A in Julia:

abstract A
function mysum(a::A)
  a.x + a.y
end

Implicitly any subtype should have the fields x and y for this function to work. So the functions defined on A are what set the requirements for subtypes. These functions could be written anywhere and one can imagine a situation where the functions are much more complex and the requirements are harder to spot. Is there someway to declare the requirements a subtype of an abstract type must have besides just implicitly from functions?

This seems to be related to Julia#6975 but if its not related to that could someone clarify the difference.

Finally, why would anyone want to use a type union instead of an abstract type. The abstract type is more flexible and extensible, the type union is fixed. For example

Why this:

type A
  x
end

type B
  x
end

typealias C Union{A,B}

Instead of this:

abstract C

type A <: C
  x
end

type B <: C
  x
end

Answer 1

First question: I do not think there is a way to achieve this currently, but it is at the heart of the discussions about adding traits to the language. You have already found one issue discussing this, and I believe it is on the informal roadmap beyond version 1.0 (at least I've seen it mentioned.)

I think the recommended way of implementing what you are looking for is something along these lines (note that type has been deprecated and replaced by struct):

abstract type A end

struct B <: A
    x
    y
end

struct C <: A
    w
    z
end

prop1(b::B) = b.x
prop2(b::B) = b.y
prop1(c::C) = c.w
prop2(c::C) = c.z  # changed from prop2(c::C)=c.w

mysum(a::A) = prop1(a) + prop2(a)

That is, instead of requiring B and C to have the same fields, you implement methods that define their behaviour. Then the actual field names remain internal implementation details of each concrete type.

As for union types, they can be used (among other things) to add methods to types that do not have a common supertype. Abstract types are fine, but you cannot always shoehorn all your types into a common hierarchy, and frequently you will add methods to collections of types that you did not define yourself.