I think #2 is the right solution, but I also wish there was a nicer syntax
to do it. Here's how I'd probably tackle it... if I get around to it soon
I'll post the implementation:
@abstract type AbstractFoo
bar::Int
end
@extend AbstractFoo type Foo
end
@extend AbstractFoo type Foobar
baz::Float64
end
# then:
Foo <: AbstractFoo
Foobar <: AbstractFoo
and both Foo and Foobar have a field bar.
I suspect this will be dirt-simple to implement for non-parametrics, but
might be a little tricky otherwise. It's just a matter of injecting fields
(and parameters) into the proper spot of the type definition.
On Mon, Sep 12, 2016 at 6:00 PM, Chris Rackauckas <rackd...@gmail.com>
wrote:
> 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 <rack...@gmail.com>
>> 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-in
>>> heritance-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 <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 <
>>>>> mkborr...@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
>>>>>>
>>>>>>
>>>>>
>>
