Hey folks,


So in working with the allocator, a common matter has come again to the fore: I need to forward certain functions to a member. Consider code in https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/free_tree.d:

struct FreeTree(ParentAllocator)
{
    ...

    static if (hasMember!(ParentAllocator, "expand"))
    bool expand(ref void[] b, size_t delta)
    {
        return parent.expand(b, delta);
    }

    static if (hasMember!(ParentAllocator, "reallocate"))
    bool reallocate(ref void[] b, size_t n)
    {
        return parent.reallocate(b, n);
    }

    static if (hasMember!(ParentAllocator, "allocateAll"))
    void[] allocateAll()
    {
        return parent.allocateAll;
    }
}

A simple solution have FreeTree support these functions would be to use simple subtyping with alias this. However, I'd like more control than that - yes, I want forwarding to work but not accessing the parent object directly.

So I'm thinking of defining a mixin that would be used like this:

struct FreeTree(ParentAllocator)
{
    ...
    mixin(forwardIfDefined("parent",
        "expand", "reallocate", "allocateAll"));
}

and, boom, all appropriate forwarding is generated, either with sheer definitions or by using opDispatch.

Furthermore, we should probably define this for Phobos because it's a common thing people like to do.

Before embarking on this, does anyone have some code around that does that kind of stuff?


Andrei

Sounds similar to http://dlang.org/phobos/std_typecons.html#.Proxy

On Sunday, 3 May 2015 at 00:25:13 UTC, Dicebot wrote:
> Sounds similar to http://dlang.org/phobos/std_typecons.html#.Proxy

That's a good idea. Proxy could be improved to take a list of names of members to forward. That'd be pretty cool actually.

On 5/2/15 5:42 PM, Meta wrote:
> On Sunday, 3 May 2015 at 00:25:13 UTC, Dicebot wrote:
>> Sounds similar to http://dlang.org/phobos/std_typecons.html#.Proxy
>
> That's a good idea. Proxy could be improved to take a list of names of
> members to forward. That'd be pretty cool actually.

Here's what I have right now - simple as they come: http://dpaste.dzfl.pl/7ec11459a125. Kudos to whoever defined ParameterTypeTuple, it's exactly what the doctor prescribed.

The gist of it is:

string forwardToMember(string member, string[] funs...)
{
    string result;
    foreach (fun; funs)
    {
        result ~= "
            auto "~fun~"(ParameterTypeTuple!(typeof("~member~"."~fun~")) args)
            {
                return "~member~"."~fun~"(args);
            }
        ";
    }
    return result;
}

which is used as:

    mixin(forwardToMember("member", "expand", "reallocate", "owns"));

Is this a common thing people wanna do? Put in Phobos?


Andrei

On Sunday, 3 May 2015 at 04:20:46 UTC, Andrei Alexandrescu wrote:
> On 5/2/15 5:42 PM, Meta wrote:
>> On Sunday, 3 May 2015 at 00:25:13 UTC, Dicebot wrote:
> Here's what I have right now - simple as they come: http://dpaste.dzfl.pl/7ec11459a125. Kudos to whoever defined ParameterTypeTuple, it's exactly what the doctor prescribed.
>
> The gist of it is:
>
> string forwardToMember(string member, string[] funs...)
> {
>     string result;
>     foreach (fun; funs)
>     {
>         result ~= "
>             auto "~fun~"(ParameterTypeTuple!(typeof("~member~"."~fun~")) args)
>             {
>                 return "~member~"."~fun~"(args);
>             }
>         ";
>     }
>     return result;
> }
>
> which is used as:
>
>     mixin(forwardToMember("member", "expand", "reallocate", "owns"));
>
> Is this a common thing people wanna do? Put in Phobos?
>
>
> Andrei

Is there any particular reason to generate 1 function per parent function? I was actually surprised the following doesn't work:

struct Test1
{
	void foo(string) { writeln("Test1 foo"); }
	int bar(int) { writeln("Test1 bar"); return 0; }
	void baz() { writeln("Test1 baz"); }
}

struct TestWrapper(T)
{
	T parent;
	
	alias foo = parent.foo;
	alias bar = parent.bar;
	alias baz = parent.baz;
}

void main()
{
	TestWrapper!Test1 t;

        //Error: this for foo needs to be type Test1 not type TestWrapper!(Test1)
	t.foo("test");

        //ditto
	t.bar(2);

        //ditto
	t.baz();
}

It seems like it'd be a lot cheaper and cleaner to just be able to alias the parent method. Also, it could probably be made a bit simpler with opDispatch.

On 5/2/15 10:00 PM, Meta wrote:
> It seems like it'd be a lot cheaper and cleaner to just be able to alias
> the parent method.

Yeh, that's the first solution that comes to mind. alias doesn't work here but of course we could change the language.

> Also, it could probably be made a bit simpler with
> opDispatch.

I'd have to see the code, but my intuition is that things could get quite a bit more hairy.


Andrei

On Sunday, 3 May 2015 at 05:49:52 UTC, Andrei Alexandrescu wrote:
> On 5/2/15 10:00 PM, Meta wrote:
>> It seems like it'd be a lot cheaper and cleaner to just be able to alias
>> the parent method.
>
> Yeh, that's the first solution that comes to mind. alias doesn't work here but of course we could change the language.
>
>> Also, it could probably be made a bit simpler with
>> opDispatch.
>
> I'd have to see the code, but my intuition is that things could get quite a bit more hairy.
>
>
> Andrei

IMO, using __traits and opDispatch is a fair bit cleaner, and I prefer the syntax of a mixin template to regular mixin.

http://dpaste.dzfl.pl/d60498246577

Wow, ParameterTypeTuple even works with ref arguments with no problem. That's impressive.

On Sunday, 3 May 2015 at 00:25:13 UTC, Dicebot wrote:
> Sounds similar to http://dlang.org/phobos/std_typecons.html#.Proxy

Great documentation by the way. I understood what it does with one read:

"Make proxy for a."

On Sunday, 3 May 2015 at 07:55:30 UTC, tcak wrote:
> On Sunday, 3 May 2015 at 00:25:13 UTC, Dicebot wrote:
>> Sounds similar to http://dlang.org/phobos/std_typecons.html#.Proxy
>
> Great documentation by the way. I understood what it does with one read:
>
> "Make proxy for a."

http://dlang.org/phobos-prerelease/std_typecons.html#.Proxy