Inheritance of mixin

[tsbockman via Digitalmars-d]

On Friday, 29 April 2016 at 00:32:54 UTC, Andrew Benton wrote:
> On Thursday, 28 April 2016 at 12:28:23 UTC, tsbockman wrote:
>> (I'll skip your example code here, since it has some problems 
>> and won't compile without significant changes.)
>
> I'm not sure what issues you're having that are significant.  I 
> forgot to close a string, but the rest compiles and executes 
> for me.

With version = both :

     Deprecation: implicitly overriding base class method 
app.Base.WriteName!().writeName with 
app.Inheritor.WriteName!().writeName deprecated; add 'override' 
attribute

Trying again, I see that it actually does compile since it's a 
deprecation, and not an error - but still this should be fixed, 
and doing so requires restructuring your code.

> What I'm trying to get at is that I want to add behavior to a 
> hierarchy.  I know that I can get that done in a _really_ light 
> example with a templated function, or in a heavier example by 
> repeating my code.  The problem with the former is that it 
> doesn't actually cover my use case.  The problem with the later 
> is that any architect that sees that amount of repetition will 
> likely start pulling their hair out.

That's quite an exaggeration. One extra line of code per derived 
class is not a hair-pulling level or repetition.

> What are the reasons that mixin shouldn't be able to be used to 
> change the behavior of a whole hierarchy?

Mixins are a fairly simple and elegant feature both to use, and 
to implement in the compiler. Your proposal kills that 
simplicity, in the name of saving one line of code per class for 
a rare use case.