It's non-orthogonal because subtyping becomes about sharing both behavior and structure, not just behavior. An orthogonal approach would use an independent feature for sharing structure. This is all covered in the discussion in https://github.com/JuliaLang/julia/issues/4935.
> On Jun 21, 2014, at 9:59 AM, Abe Schneider <[email protected]> wrote: > > I think that's a fair point (though I may disagree that it's non-othogonal). > My main point is that you are already implicitly using a hierarchical > structure with grouping. Therefore, I don't see this as adding a new feature > to the language, it's already something you can do in Julia, but rather > providing the syntax to allow the relationship to be declared in useful way. > > The code: > abstract A > x::Int64 > end > > type B <: A > y::Int64 > end > > type C <: A > z::Float64 > end > > > is much clearer to me than: > type A > int x::Int64 > end > > abstract AType > getx(a::AType) = a.x > setx(a::AType, x::Int64) = a.x = x > > type B <: AType > parent::A > end > > type C <: AType > parent::C > end > > > or: > abstract A > > type B <: A > x::Int64 > y::Int64 > end > > type C <: A > x::Int64 > z::Float64 > end > > > The last two examples violate DRY, make for potentially difficult to maintain > code, and are less obvious to someone else looking at the code as to what is > happening. > >> On Saturday, June 21, 2014 9:02:52 AM UTC-4, Stefan Karpinski wrote: >> The harm is adding unnecessary, non-orthogonal language features. We've >> tended not to add features until it becomes very clear that we need them and >> why, and that's been a good approach so far. Aside from several discussions >> similar to this, I don't feel like the problems this feature would alleviate >> are especially pressing. So far subtyping in Julia is purely about behavior, >> not structure and changing that even a little bit would require some >> significant motivation – certainly more than "why not?" >> >>> On Jun 21, 2014, at 8:45 AM, Abe Schneider <[email protected]> wrote: >>> >>> After some thought, it occurred to me that with the grouping you suggested, >>> you are really implementing a type of inheritance. If you rename your >>> sub-type as 'parent' you have: >>> >>> type ParentClass >>> # vars >>> end >>> >>> abstract ParentClassType >>> >>> type ChildClass <: ParentClassType >>> parent::ParentClass >>> # vars >>> end >>> >>> which is exactly what a Mixin paradigm would accomplish, only that the >>> compiler would help with the construction (which at the end of the day is >>> all OOP really is). If this type of construction can be done by hand, I'm >>> not sure what the harm is in having the compiler make things easier. >>> >>>> On Saturday, June 21, 2014 3:09:36 AM UTC-4, Tobias Knopp wrote: >>>> When I switched from C++ to C# I had a similar opinion about the issue of >>>> duplicated fields in all classes implementing an interface. But when >>>> getting used to grouping things together and using has-a relations this >>>> has changed my thinking about it. >>>> I now think that it enforces structuring code in a sane way. When >>>> inheriting field members one often observes far to late that one has >>>> structural issues and refactoring then becomes really hard. >>>> >>>> When looking at Julia base code (or several of the packages) one will see >>>> that the issue of inheriting field members does not come up so much. >>>> >>>> One side comment. In Julia the possibility to use duck typing gives a lot >>>> of flexibility. And when one reaches limits (e.g. due to the absence of >>>> abstract multiple inheritance) duck typing is often a solution. >>>> >>>> Am Samstag, 21. Juni 2014 03:43:57 UTC+2 schrieb Abe Schneider: >>>>> >>>>> I agree, I think it's the best solution given the tools (and what I'm >>>>> going to use for my code). However, it still feels more like a hack >>>>> around the design than good programming practice. >>>>> >>>>> On Friday, June 20, 2014 5:41:02 PM UTC-4, Spencer Russell wrote: >>>>>> >>>>>> I'd just like to second Jameson's suggestion of aggregating the common >>>>>> fields into a type that all your subclasses contain. >>>>>> >>>>>> I did quite a bit of thinking on this issue when it came up in AudioIO, >>>>>> and was lucky enough to have both Jeff and Stefan around to bounce ideas >>>>>> off of. >>>>>> >>>>>> My main issues with the duplicated data in subclasses were: >>>>>> It's annoying to have to add the same set of fields every time you >>>>>> define a subtype, and violates DRY. It's also error prone. >>>>>> If you want to add a feature to the base type that requires a new field, >>>>>> EVERYONE WHO EVER SUBTYPED your base type now has to add the field to >>>>>> their subtype. It's bad enough when this is within your own codebase, >>>>>> but if there's other code subtyping it then you're really in trouble. >>>>>> Encapsulating the common fields solves both those issues.If you want to >>>>>> add new fields later on you can just add them to the aggregating type. >>>>>> Most importantly, it does it in really easy-to-reason-about way, without >>>>>> adding any tricky edge cases or complicated rules for developers to >>>>>> understand. >>>>>> >>>>>> peace, >>>>>> s >>>>>> >>>>>> >>>>>>> On Fri, Jun 20, 2014 at 3:57 PM, Abe Schneider <[email protected]> >>>>>>> wrote: >>>>>>> I was thinking something along those lines, but as was pointed out, you >>>>>>> would have to also create the constructors. >>>>>>> >>>>>>> Unfortunately, I'm on my phone right now, so I can't effectively post >>>>>>> code. I was thinking of a 'mixin' macro which would create a new type >>>>>>> (with constructor): >>>>>>> >>>>>>> @mixin Foo <: Bar Baz >>>>>>> >>>>>>> Would create Foo from both Bar and Baz. However, because there is no >>>>>>> MI, you could only inherit from Bar. >>>>>>> >>>>>>> While it does have some magic to it, it might not be awful. Also, you >>>>>>> could still make an outer constructor for it. >>>>>>> >>>>>>> Of course, I don't know the actual technical challenges to making it, >>>>>>> since I haven't had time to write any code. >>>>>>
