Ahh, that makes a lot of sense as well. I can see how that would make everything a lot harder to optimize. Thanks for the explanation!
On Monday, September 12, 2016 at 2:44:22 PM UTC-7, Stefan Karpinski wrote: > > The biggest practical issue is that if you can subtype a concrete type > then you can't store values inline in an array, even if the values are > immutable – since a subtype can be bigger than the supertype. This leads to > having things like "final" classes, etc. Fundamentally, this is really an > issue of failing to separate the concrete type – which is complete and can > be instantiated – from the abstract type, which is incomplete and can be > subtyped. > > On Mon, Sep 12, 2016 at 3:17 PM, Chris Rackauckas <[email protected] > <javascript:>> wrote: > >> https://en.wikipedia.org/wiki/Composition_over_inheritance >> >> >> http://programmers.stackexchange.com/questions/134097/why-should-i-prefer-composition-over-inheritance >> >> >> https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose >> >> That's just the start. Overtime, people realized inheritance can be quite >> fragile, so many style guidelines simply forbid you from doing it. >> >> On Monday, September 12, 2016 at 11:45:40 AM UTC-7, Bart Janssens wrote: >>> >>> 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 <[email protected]> >>> 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 < >>>> [email protected]> 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 >>>>> >>>>> >>>> >
