Looking at this example, it seems mighty tempting to have the ability to subtype a concrete type. Are the exact problems with that documented somewhere? I am aware of the following section in the docs:
"One particularly distinctive feature of Julia’s type system is that concrete types may not subtype each other: all concrete types are final and may only have abstract types as their supertypes. While this might at first seem unduly restrictive, it has many beneficial consequences with surprisingly few drawbacks. It turns out that being able to inherit behavior is much more important than being able to inherit structure, and inheriting both causes significant difficulties in traditional object-oriented languages." I'm just wondering what the "significant difficulties" are, not advocating changing this behaviour. On Mon, Sep 12, 2016 at 5:28 PM Stefan Karpinski <ste...@karpinski.org> wrote: > I would probably go with approach #2 myself and only refer to the .bar and > .baz fields in all of the generic AbstractFoo methods. > > On Mon, Sep 12, 2016 at 10:10 AM, Michael Borregaard < > mkborrega...@gmail.com> wrote: > >> Hi, >> >> I am defining a set of types to hold scientific data, and trying to get >> the best out of Julia's type system. The types in my example are 'nested' >> in the sense that each type will hold progressively more information and >> thus allow the user to do progressively more. Like this: >> >> type Foo >> bar >> baz >> end >> >> type Foobar >> bar # this >> baz # and this are identical with Foo >> barbaz >> bazbaz >> end >> >> >
