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