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: >> >> 1. 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. >> 2. 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. >>> >> >>
