Is there any nifty D features that allow one to simplify the composite pattern,

e.g.,

    class A : B
    {
        B b;
    }

Where I would like to have class A's implementation of B be use b. This would avoid a lot of boilerplate code if just redirecting A's implementation of B to b.

e.g.,

   class A : B(use b)
   {
       B b;
   }


or maybe more D'ish

   class A : B
   {
      B b;
      alias b A:B;
   }

probably some fancy mixin could be used:

   class A : B
   {
      B b;
      mixin simpleComposite(b);   // Just implements B with redirection to b
   }

On Wednesday, 3 July 2013 at 10:12:34 UTC, JS wrote:
> ...

class A
{
    B b;
    alias b this;
}

?

On Wednesday, 3 July 2013 at 10:41:02 UTC, Dicebot wrote:
> On Wednesday, 3 July 2013 at 10:12:34 UTC, JS wrote:
>> ...
>
> class A
> {
>     B b;
>     alias b this;
> }
>
> ?

Sorry, I left out one important detail, B is an interface so A has to implement B's methods. If B were class then this would not be a problem and alias this would not be required, and I could easily override any implementation details.

interface B { void foo(); }

class A : B { B b; void foo() { return b.foo(); } }

For each method in B, I have to write a duplicate method in A that redirects to b. I do not want to do this and I also want to partially implement B explicitly.

I think a mixin and traits could be used, at least to implicitly implement all of B, but I'm not sure about only partially.

I'm trying to write a mixin that will solve the problem but since I can't seem to build up strings progressively it's a huge pain in the ass.


import std.stdio, std.cstream, std.traits, std.conv;

interface A { void myfunc(real, int, string); @property int myvalue(); }


template reverseEnum(alias e, alias value)
{
	string eval()
	{
		foreach(v; EnumMembers!e)
		{
			static if (to!int(v) - to!int(value) == 0)
				return to!string(v);
		}
		
		return "";
	}
	enum reverseEnum = '"' ~ eval() ~ '"';
}
template evaluateParameterTypeTuple(string x) { enum evaluateParameterTypeTuple = "ParameterTypeTuple!("~x~").stringof"; }
template evaluateReturnType(string x) { enum evaluateReturnType = "ReturnType!("~x~").stringof"; }
template evaluateAttributes(string x) { enum evaluateAttributes = "functionAttributes!("~x~")"; }
template replaceString(string x, string y, string z) { string eval() { static if(x == y) return z; return x; } enum replaceString = "'~eval()~'"';
}

template implementInterface(alias I, alias i)
{
	
	static string implement()
	{
		//string x;
		foreach(name; __traits(allMembers, I))
		{
			enum qname = I.stringof ~ "." ~ name;
			enum a = mixin(replaceString!("@"~mixin(reverseEnum!(FunctionAttribute, to!int(mixin(evaluateAttributes!(qname))))) ~ " ", "@none ", ""));
			enum bbody = " { return " ~ i.stringof ~ "." ~ name ~ "(); }";
			enum x = a ~ mixin(evaluateReturnType!(qname)) ~ " " ~ name ~ mixin(evaluateParameterTypeTuple!(qname)) ~ bbody;
			pragma(msg, ">" ~ x);
		}
		
		return "";
	}
	enum implementInterface = implement();
}

class B : A
{
	A a;
	mixin(implementInterface!(A, a));
}


void main(string[] args)
{
	din.getc();
}



The code produces results like

void myfunc(real, int, string) { return a.myfunc(); } and
@property myvalue() { return a.myvalue(); }

which at some point, when finished, can be inserted into class B to implement A.

The problem, is that I can't build up the strings progressively in the mixin templates because I get errors that the variable can't be read at compile time.

I can do stuff like

enum x = "a" ~ "b" ~ "c";

but not

enum x = "a";
x ~= "b";
x ~= "c";

or whatever...

strings are about useless as they have the same issue.

I understand that compile time evaluation needs to have static behavior but I'm not doing anything that can't be done at compile time.

I had to write a template just to replace a the "none" attribute because I couldn't easily do it directly.  I can't have the reverseEnum work with multiple flags because I can't build up the attribute string progressively. While I imagine it is possible to hack it up by tricking the compiler it starts to feel C'sh with something that should be pretty simple...

Maybe someone has some ideas?

2013/7/4 JS <js.mdnq@gmail.com>

> I'm trying to write a mixin that will solve the problem but since I can't seem to build up strings progressively it's a huge pain in the ass.
>

How about this?
Unfortunately this code doesn't work with git head, because it requires
both one small std.typecons.wrap bug fix and its one small improvement. But
I'll make a PR to fix them soon.

// -------------
// core side

import std.typecons : Proxy;
import std.typecons : wrap, unwrap;
import std.typecons : WhiteHole, NotImplementedError;
import std.exception : enforce;

public interface Interface
{
    int foo();
    int bar();
}

private class Pluggable
{
    Interface impl;
    mixin Proxy!impl;

    static Interface defaultImpl;
    static this() { defaultImpl = new WhiteHole!Interface(); }

    this() { impl = defaultImpl; }

    int foo() { return 1; }     // pre-defined default behavior
}

public Interface createPluggable()
{
    return new Pluggable().wrap!Interface;
}
public Interface setPlugin(Interface i, Interface plugin)
{
    Pluggable p = enforce(i.unwrap!Pluggable);
    p.impl = plugin ? plugin : Pluggable.defaultImpl;
    return i;
}

// -------------
// user side

class Plugin : Interface
{
    override int foo() { return 10; }
    override int bar() { return 20; }
}

void main()
{
    import std.exception : assertThrown;

    Interface i = createPluggable();

    assert(i.foo() == 1);
    assertThrown!NotImplementedError(i.bar());

    i.setPlugin(new Plugin());  // set plug-in

    assert(i.foo() == 1);
    assert(i.bar() == 20);

    i.setPlugin(null);          // remove plug-in

    assert(i.foo() == 1);
    assertThrown!NotImplementedError(i.bar());
}

Kenji Hara

On Wednesday, 3 July 2013 at 10:12:34 UTC, JS wrote:
> Is there any nifty D features that allow one to simplify the composite pattern,
>
> e.g.,
>
>     class A : B
>     {
>         B b;
>     }
>
> Where I would like to have class A's implementation of B be use b. This would avoid a lot of boilerplate code if just redirecting A's implementation of B to b.
>
> e.g.,
>
>    class A : B(use b)
>    {
>        B b;
>    }
>
>
> or maybe more D'ish
>
>    class A : B
>    {
>       B b;
>       alias b A:B;
>    }
>
> probably some fancy mixin could be used:
>
>    class A : B
>    {
>       B b;
>       mixin simpleComposite(b);   // Just implements B with redirection to b
>    }

You can also try to overload opCast() in the container class, a bit in the same fashion that the 'alias this' stuff (except that alias this will not work with many sub classes). The idea is exposed here:

http://dpaste.dzfl.pl/33d1b2c3

On Thursday, 4 July 2013 at 07:03:39 UTC, Baz wrote:
> On Wednesday, 3 July 2013 at 10:12:34 UTC, JS wrote:
>> Is there any nifty D features that allow one to simplify the composite pattern,
>>
>> e.g.,
>>
>>    class A : B
>>    {
>>        B b;
>>    }
>>
>> Where I would like to have class A's implementation of B be use b. This would avoid a lot of boilerplate code if just redirecting A's implementation of B to b.
>>
>> e.g.,
>>
>>   class A : B(use b)
>>   {
>>       B b;
>>   }
>>
>>
>> or maybe more D'ish
>>
>>   class A : B
>>   {
>>      B b;
>>      alias b A:B;
>>   }
>>
>> probably some fancy mixin could be used:
>>
>>   class A : B
>>   {
>>      B b;
>>      mixin simpleComposite(b);   // Just implements B with redirection to b
>>   }
>
> You can also try to overload opCast() in the container class, a bit in the same fashion that the 'alias this' stuff (except that alias this will not work with many sub classes). The idea is exposed here:
>
> http://dpaste.dzfl.pl/33d1b2c3

This isn't what I'm really after. At some point I might want to implement the interface partially.

interface A { ... }
class B : A {
   A a;
   // implementation of A goes here, but I'd like it to just redirect to a for all that I do not explicitly implement //
}

There seems to be some cool stuff that Kenji has used that I was not familiar with. I'm not quite sure if it does exactly what I'm asking but it looks close.

On Thursday, 4 July 2013 at 05:57:45 UTC, Kenji Hara wrote:
> 2013/7/4 JS <js.mdnq@gmail.com>
>
>> I'm trying to write a mixin that will solve the problem but since I can't
>> seem to build up strings progressively it's a huge pain in the ass.
>>
>
> How about this?
> Unfortunately this code doesn't work with git head, because it requires
> both one small std.typecons.wrap bug fix and its one small improvement. But
> I'll make a PR to fix them soon.
>
> // -------------
> // core side
>
> import std.typecons : Proxy;
> import std.typecons : wrap, unwrap;
> import std.typecons : WhiteHole, NotImplementedError;
> import std.exception : enforce;
>
> public interface Interface
> {
>     int foo();
>     int bar();
> }
>
> private class Pluggable
> {
>     Interface impl;
>     mixin Proxy!impl;
>
>     static Interface defaultImpl;
>     static this() { defaultImpl = new WhiteHole!Interface(); }
>
>     this() { impl = defaultImpl; }
>
>     int foo() { return 1; }     // pre-defined default behavior
> }
>
> public Interface createPluggable()
> {
>     return new Pluggable().wrap!Interface;
> }
> public Interface setPlugin(Interface i, Interface plugin)
> {
>     Pluggable p = enforce(i.unwrap!Pluggable);
>     p.impl = plugin ? plugin : Pluggable.defaultImpl;
>     return i;
> }
>
> // -------------
> // user side
>
> class Plugin : Interface
> {
>     override int foo() { return 10; }
>     override int bar() { return 20; }
> }
>
> void main()
> {
>     import std.exception : assertThrown;
>
>     Interface i = createPluggable();
>
>     assert(i.foo() == 1);
>     assertThrown!NotImplementedError(i.bar());
>
>     i.setPlugin(new Plugin());  // set plug-in
>
>     assert(i.foo() == 1);
>     assert(i.bar() == 20);
>
>     i.setPlugin(null);          // remove plug-in
>
>     assert(i.foo() == 1);
>     assertThrown!NotImplementedError(i.bar());
> }
>
> Kenji Hara

Unfortunately I can't test it until head is updated but it looks close to what I'm wanting... not 100% sure though. At the very least wrap is something similar to what I was trying to implement more or less so I can look in that for details if I need to.

On Thursday, 4 July 2013 at 09:26:24 UTC, JS wrote:
> On Thursday, 4 July 2013 at 07:03:39 UTC, Baz wrote:
>> On Wednesday, 3 July 2013 at 10:12:34 UTC, JS wrote:
>>> Is there any nifty D features that allow one to simplify the composite pattern,
>>>
>>> e.g.,
>>>
>>>   class A : B
>>>   {
>>>       B b;
>>>   }
>>>
>>> Where I would like to have class A's implementation of B be use b. This would avoid a lot of boilerplate code if just redirecting A's implementation of B to b.
>>>
>>> e.g.,
>>>
>>>  class A : B(use b)
>>>  {
>>>      B b;
>>>  }
>>>
>>>
>>> or maybe more D'ish
>>>
>>>  class A : B
>>>  {
>>>     B b;
>>>     alias b A:B;
>>>  }
>>>
>>> probably some fancy mixin could be used:
>>>
>>>  class A : B
>>>  {
>>>     B b;
>>>     mixin simpleComposite(b);   // Just implements B with redirection to b
>>>  }
>>
>> You can also try to overload opCast() in the container class, a bit in the same fashion that the 'alias this' stuff (except that alias this will not work with many sub classes). The idea is exposed here:
>>
>> http://dpaste.dzfl.pl/33d1b2c3
>
> This isn't what I'm really after. At some point I might want to implement the interface partially.
>
> interface A { ... }
> class B : A {
>    A a;
>    // implementation of A goes here, but I'd like it to just redirect to a for all that I do not explicitly implement //
> }
>
> There seems to be some cool stuff that Kenji has used that I was not familiar with. I'm not quite sure if it does exactly what I'm asking but it looks close.

You're right, actually my answer was a bit off-topic since it was mostly related to the first 'Dicebot' answer and the 'alias this' stuff. BTW it's not perfect since using the opCast doesn't allow to 'mirror' several Objects of the same class...