I'm running into a set of problems where both inheritance and mixin-added functionality really lend a hand to my project.  Unfortunately, they don't necessarily work well together, as certain mixins need to be restated for each inheritor.

As a toy example, if I wanted to mixin some functionality to write names:

mixin template WriteName()
{
    string writeName()
    {
        import std.uuid : randomUUID;
        static if(__traits(hasMember, this, "name"))
            return __traits(getMember, this, "name);
        else
            return randomUUID.toString;
    }
}
class Base
{
    mixin WriteName;
}
class Inheritor : Base
{
    version(both) mixin WriteName;
    string name = "test";
}

In the above example, unless I used version "both", I would see only random UUIDs from instances of Base and Inheritor, however the functionality that I really want is to get random UUIDs only from Base, and get "test" from Inheritor.  So far as I know, the easiest way to fix this is to add that mixin to each descendant of Base.

I recognize that, at least for this toy example, an easier fix is to use a templated function, however I'm more interested in libraries like jsonizer and witchcraft.

So to the point: Is there an easier way to do this that I'm missing?  Is there a language-design reason that mixed in templates can't inherit?  It seems like an intuitive use of mixin.

On Thursday, 28 April 2016 at 10:21:34 UTC, Andrew Benton wrote:
> So to the point: Is there an easier way to do this that I'm missing?  Is there a language-design reason that mixed in templates can't inherit?  It seems like an intuitive use of mixin.

Mixins are (mostly) just a convenient way to generate code, given some parameters. They aren't supposed to work any differently than the same code would if you instantiated the mixin by hand and inserted its contents at each usage site.

(I'll skip your example code here, since it has some problems and won't compile without significant changes.) The manual (mixin-free) code to do what you want looks like this:

class Base
{
    string writeName()
    {
        import std.uuid : randomUUID;
        return randomUUID.toString;
    }
}
class Inheritor : Base
{
    override string writeName()
    {
        return name;
    }
    string name = "test";
}

Doing this manually requires that some code be added to Inheritor. Using a mixin doesn't - and shouldn't - change this.

What a mixin could do for you in this situation, is consolidate duplicate code if there are many Inheritor classes:

mixin template WithName(string name0)
{
    override string writeName()
    {
        return name;
    }
    string name = name0;
}

class Inheritor1 : Base
{
    mixin WithName!"test1";
}
class Inheritor2 : Base
{
    mixin WithName!"test2";
}

Alternatively, you could just use inheritance (assuming that your needs can reasonably be expressed through single inheritance):

class NamedBase : Base
{
    override string writeName()
    {
        return name;
    }
    string name;

    this(string name0)
    {
        name = name0;
    }
}

class Inheritor3 : NamedBase
{
    this()
    {
        super("test3");
    }
}
class Inheritor4 : NamedBase
{
    this()
    {
        super("test4");
    }
}

Try it on DPaste: http://dpaste.dzfl.pl/5595bd09391f

On Thursday, 28 April 2016 at 10:21:34 UTC, Andrew Benton wrote:
> I'm running into a set of problems where both inheritance and mixin-added functionality really lend a hand to my project.  Unfortunately, they don't necessarily work well together, as certain mixins need to be restated for each inheritor.
>
> As a toy example, if I wanted to mixin some functionality to write names:
>
> mixin template WriteName()
> {
>     string writeName()
>     {
>         import std.uuid : randomUUID;
>         static if(__traits(hasMember, this, "name"))
>             return __traits(getMember, this, "name);
>         else
>             return randomUUID.toString;
>     }
> }
> class Base
> {
>     mixin WriteName;
> }
> class Inheritor : Base
> {
>     version(both) mixin WriteName;
>     string name = "test";
> }
>
> In the above example, unless I used version "both", I would see only random UUIDs from instances of Base and Inheritor, however the functionality that I really want is to get random UUIDs only from Base, and get "test" from Inheritor.  So far as I know, the easiest way to fix this is to add that mixin to each descendant of Base.
>
> I recognize that, at least for this toy example, an easier fix is to use a templated function, however I'm more interested in libraries like jsonizer and witchcraft.
>
> So to the point: Is there an easier way to do this that I'm missing?  Is there a language-design reason that mixed in templates can't inherit?  It seems like an intuitive use of mixin.

This is a common error with mixin template. The static things gets only evaluated once. If you want to be evaluated in each class type you need a true template that get an instance in each class. However the method then **wont be virtual** !!

----
mixin template WriteName()
{
    string writeName(this T)()
    {
        import std.uuid : randomUUID;
        static if (__traits(hasMember, T, "name"))
            return __traits(getMember, cast(T)this, "name");
        else
            return randomUUID.toString;
    }
}
class Base
{
    mixin WriteName;
}
class Inheritor : Base
{
    string name = "test";
}

void main()
{
    import std.stdio;
    writeln((new Base).writeName!Base); // an UUID
    writeln((new Inheritor).writeName!Inheritor); // test
}
----

see template this parameter:

https://dlang.org/spec/template.html#TemplateThisParameter

On Thursday, 28 April 2016 at 12:41:57 UTC, Basile B. wrote:
> On Thursday, 28 April 2016 at 10:21:34 UTC, Andrew Benton wrote:
>> [...]
>
> This is a common error with mixin template. The static things gets only evaluated once. If you want to be evaluated in each class type you need a true template that get an instance in each class. However the method then **wont be virtual** !!
>
> [...]

Oops actually, type is infered:

void main()
{
    import std.stdio;
    writeln((new Base).writeName); // an UUID
    writeln((new Inheritor).writeName); // test
}

On Thursday, 28 April 2016 at 12:28:23 UTC, tsbockman wrote:
> On Thursday, 28 April 2016 at 10:21:34 UTC, Andrew Benton wrote:
>> So to the point: Is there an easier way to do this that I'm missing?  Is there a language-design reason that mixed in templates can't inherit?  It seems like an intuitive use of mixin.
>
> Mixins are (mostly) just a convenient way to generate code, given some parameters. They aren't supposed to work any differently than the same code would if you instantiated the mixin by hand and inserted its contents at each usage site.

I understand that is the point of mixin, as it exists today.  It also seems like it isn't capable of what I want.

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

> Doing this manually requires that some code be added to Inheritor. Using a mixin doesn't - and shouldn't - change this.

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.  What are the reasons that mixin shouldn't be able to be used to change the behavior of a whole hierarchy?

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.

On 29.04.2016 07:35, tsbockman wrote:
>
>> 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,

It is not complicated, we'd just need a way to specify that a mixin should be inserted into all subclasses.

> in the name of saving one line of code per class for a rare use case.

The use case isn't rare (it is a quite popular request, at least four independent instances that I remember).

Having a mixin in all classes in some subtree of the class hierarchy can be a good idea. Of course one can easily do it manually, but it is always nice to get rid of boilerplate.

On Friday, 29 April 2016 at 10:59:20 UTC, Timon Gehr wrote:
> On 29.04.2016 07:35, tsbockman wrote:
>> in the name of saving one line of code per class for a rare use case.
>
> The use case isn't rare (it is a quite popular request, at least four independent instances that I remember).

Rare as in, "effecting only a very small amount of real world code" - not as in "effecting only a very small number of people".

2016-04-29 21:11 GMT+02:00 tsbockman via Digitalmars-d < digitalmars-d@puremagic.com>:

> On Friday, 29 April 2016 at 10:59:20 UTC, Timon Gehr wrote:
>
>> On 29.04.2016 07:35, tsbockman wrote:
>>
>>> in the name of saving one line of code per class for a rare use case.
>>>
>>
>> The use case isn't rare (it is a quite popular request, at least four independent instances that I remember).
>>
>
> Rare as in, "effecting only a very small amount of real world code" - not as in "effecting only a very small number of people".
>

Anyone wanting to implement double dispatch would benefit from it, for
starters. Like DMD.
As OP showed, there are others use cases which are legit. That's something
one usually expects from D, given the amount of boilerplate you can avoid
compared to other languages.

On Friday, 29 April 2016 at 19:11:24 UTC, tsbockman wrote:
> Rare as in, "effecting only a very small amount of real world code" - not as in "effecting only a very small number of people".

I'm not sure if actually affects just a small number of real world cases.  I think that majority of medium to large projects will want to apply some sort of behavior to multiple hierarchies.

Additionally, any libraries that provide a base class with a mixin require inheritors to know about that mixin and provide it in their own code.  It certainly isn't going to happen in every case, but if the needed functionality is provided by mixins, then users of the library could have problems.