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. >>>>
