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 <abe.sc...@gmail.com > <javascript:>> 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. >> > >
