pron is right: you can inherit behavior from abstract types and abstract types, unlike interfaces, can have code written to them. (In single-dispatch OO languages, you are in the strange situation that you can write code to interfaces if they are arguments but not if they are the receiver of a method; thus, you're in a situation where you can either dispatch on an interface or you can write code for it, but never both at the same time.)
Arrays are not fixed size: there are push, pop, shift and unshift operations on them just like Perl, Ruby, etc. This uses the usual allocation-doubling approach so that the entire array doesn't need to be copied every time, but it's still usually much better to pre-allocate the correct size. Of course for small arrays that are typical in Perl, Ruby, etc., it hardly matters. If you're building an vector of 1 billion floats, however, you don't want to grow it incrementally.
The sequence/iterable abstraction is duck-typed: an object has to implement methods for three generic functions:
i = start(x)
done(x,i)
next(x,i)
The state i can be anything.
Lack of implementation inheritance is one of those things that intro to OO books make a big deal of, but when you don't have it, you don't miss it at all — or at least I don't. I've never found tacking a few fields onto the end of an object to be very useful. I don't want to inherit memory layout — I want to inherit behavior. Julia's type system lets you write behavior to abstract types and inherit that for various potentially completely different underlying implementations.
I don't know if I'd call it duck-typing when methods are not grouped into interfaces. I think you could say that in Julia, each method is an interface. I find it much cleaner than actual "duck-typing" (the way it's done in , say, Scala with structural types) because then you have both an interface, which specifies a contract, as well as the method name, which also specifies a contract when duck-typing is used, even when it's found in different interfaces.
Must compound types in Julia be concrete? I don't think I saw it in the documentation.
It's been discussed, and would be satisfying to have an `Iterable` abstract type and ensure that every object implements `Iterable` satisfies contract of having appropriate `start`, `done` and `next` methods, but that requires two features we don't have yet: multiple inheritance of abstract types, and some way of specifying an interface. There's been some discussion of this, and I believe we have the way multiple inheritance could work mostly worked out; enforcement of interface implementation, not so much. However, it's a pretty massive undertaking to add it to the language. Quick teaser: generic functions and final concrete types actually make multiple dispatch work a lot better than it does with single dispatch and the "bag of named methods inside an object" model of traditional OO.
So far we haven't actually felt a "pressing need" for multiple inheritance or interfaces, and we tend to take a pressing-need approach to language features. If you can live without a feature for a while, then maybe you really didn't need it in the first place. But we'll have to see what happens when other people are starting to try to use if for things.
Aren't compound types inherently concrete? The compoundness describes the implementation of the type, implying that it must have an implementation, hence must be concrete.
Arrays are not fixed size: there are push, pop, shift and unshift operations on them just like Perl, Ruby, etc. This uses the usual allocation-doubling approach so that the entire array doesn't need to be copied every time, but it's still usually much better to pre-allocate the correct size. Of course for small arrays that are typical in Perl, Ruby, etc., it hardly matters. If you're building an vector of 1 billion floats, however, you don't want to grow it incrementally.
The sequence/iterable abstraction is duck-typed: an object has to implement methods for three generic functions:
The state i can be anything.Lack of implementation inheritance is one of those things that intro to OO books make a big deal of, but when you don't have it, you don't miss it at all — or at least I don't. I've never found tacking a few fields onto the end of an object to be very useful. I don't want to inherit memory layout — I want to inherit behavior. Julia's type system lets you write behavior to abstract types and inherit that for various potentially completely different underlying implementations.