On Monday, 4 May 2015 at 01:01:05 UTC, Andrei Alexandrescu wrote:
> Hmm, I didn't try it assuming it won't work (thought __traits(getMember, member, sym) would fail with opDispatch). Tried it just now, it does work like a charm. Thanks!
>
> Andrei

So is a function that generates a string mixin necessary or not necessary?

On 5/3/15 8:13 PM, Meta wrote:
> On Monday, 4 May 2015 at 01:01:05 UTC, Andrei Alexandrescu wrote:
>> Hmm, I didn't try it assuming it won't work (thought
>> __traits(getMember, member, sym) would fail with opDispatch). Tried it
>> just now, it does work like a charm. Thanks!
>>
>> Andrei
>
> So is a function that generates a string mixin necessary or not necessary?

I'm not sure. It's a great question. In some ways a string mixin is the straight deal - you get complete control over what you generate, ultimate flexibility, and you get to inspect it if you so want. (BTW I think compiler errors in mixins should either print the failing mixin with line numbers, or make it available as a file).

But then the opDispatch solution is more structured and restricted in a good way. I think we need a bit more experience with both to figure out which is the best way to go. More specifically:

* forward to enumerated types

* distinguish static/non-static methods, and define forwarding appropriately

* define properties to forward to member variables

* alias member types and templates

* other similar stuff I didn't think of, in essence "defer stuff to this member"


Andrei

Will allocator ever be added to phobos as maybe
std.experimental.allocator for a first time ?

On 5/4/15 9:31 AM, Temtaime wrote:
> Will allocator ever be added to phobos as maybe
> std.experimental.allocator for a first time ?

Affirmative. Getting Real Close Now. -- Andrei

On 2015-05-04 07:28, Andrei Alexandrescu wrote:

> But then the opDispatch solution is more structured and restricted in a
> good way. I think we need a bit more experience with both to figure out
> which is the best way to go.

I would guess the opDispatch solution doesn't integrate so well with an already present opDispatch (if there's such a use case).

-- 
/Jacob Carlborg

On Monday, 4 May 2015 at 19:17:26 UTC, Jacob Carlborg wrote:
> On 2015-05-04 07:28, Andrei Alexandrescu wrote:
>
>> But then the opDispatch solution is more structured and restricted in a
>> good way. I think we need a bit more experience with both to figure out
>> which is the best way to go.
>
> I would guess the opDispatch solution doesn't integrate so well with an already present opDispatch (if there's such a use case).

Hmm, that's true. I guess it'd be better to start with a mixin-based solution.

That is not exactly what I requested years ago ---> http://forum.dlang.org/thread/1330792937.10754.7.camel@jonathan

On Sunday, 3 May 2015 at 18:54:45 UTC, Andrei Alexandrescu wrote:
> You're right, that is lovely! I've improved it as follows:
>
> mixin template forwardToMember(alias member, methods...)
> {
>     import std.algorithm : among;
>     import std.traits : ParameterTypeTuple;
>     template opDispatch(string sym)
>     if ((methods.length == 0 || sym.among(methods)))
>     {
>         auto ref opDispatch(
>             ParameterTypeTuple!(__traits(getMember, member, sym)) args)
>         {
>             return __traits(getMember, member, sym)(args);
>         }
>     }
> }
>
> So now ref returns are preserved and the mixin is self-contained (doesn't require imports from the outside).
>
> Compared to my solution, this has the advantage that if the child defines a method, it will take precedence over the formatted one. So that allowed me to add a feature: if no methods are specified, all are forwarded.
>
> There are a couple of ways in which this could and should be improved, most notably overloads control. Even as is it's pretty darn awesome, Meta could you please make it into a pull request? I think it should go in std.functional.
>
>
> Andrei

I have forgotten to mention that I will make a pull request for this ASAP. I have been in the process of moving and starting a new job this week and last so I only have enough time to occasionally post currently.

On Sunday, 3 May 2015 at 00:19:37 UTC, Andrei Alexandrescu wrote:
> 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.

> > So I'm thinking of defining a mixin that would be used like
> this:
>
> struct FreeTree(ParentAllocator)
> {
>     ...
>     mixin(forwardIfDefined("parent",
>         "expand", "reallocate", "allocateAll"));
> }


This was very useful, by the way, with synchronicitous timing.  I have various derivative instruments made up of legs.  For example an interest rate swap where I pay fixed cash flows on one leg and receive floating cash flows on another.  So each swap leg is itself an entity (I made them structs), and there are a collection of such legs (of differing types) comprising a swap (or FRA, FX trade etc).

The parent entity (eg a swap with a fixed leg and a float leg; or with two float legs) needs to forward calls to the legs.  Eg if you change the notional or maturity of the parent, you probably want to change the notionals of the component legs, although in special cases they might be different.

I don't want to muck about with Byzantine inheritance systems I won't likely myself remember in a year (people seem to underrate the value of coherence these days, and fragmentation doesn't help).  On the other hand I didn't fancy writing lots of boilerplate code just to forward calls to each leg (or to only one where it made sense).

So I modified forwardToMember to forwardToLegs (I need to return a Swap object, since I want to return the Swap for UFCS and the calls to leg methods return the leg itself).

setMaturityDate(DateTime maturity( calls fixLeg.setMaturity(maturity) and floatLeg.setMaturity.  And setFloatMaturity(DateTime maturity) just calls floatLeg.setMaturity(maturity) - ie the call is remapped to a different name when forwarding, so the user doesn't need to get her hands messy with the nitty gritty of the individual legs.

So now all the glue logic is specified in simple arrays that produce the requisite code at compile time.  It's easy to see what is going on, maintainable, and the parents are only a very spaced-out 100 lines.

So thank you for this, and for all the other nice features in D.

On Wednesday, 6 May 2015 at 22:59:16 UTC, Meta wrote:
> On Sunday, 3 May 2015 at 18:54:45 UTC, Andrei Alexandrescu wrote:
>> You're right, that is lovely! I've improved it as follows:
>>
>> mixin template forwardToMember(alias member, methods...)
>> {
>>     import std.algorithm : among;
>>     import std.traits : ParameterTypeTuple;
>>     template opDispatch(string sym)
>>     if ((methods.length == 0 || sym.among(methods)))
>>     {
>>         auto ref opDispatch(
>>             ParameterTypeTuple!(__traits(getMember, member, sym)) args)
>>         {
>>             return __traits(getMember, member, sym)(args);
>>         }
>>     }
>> }
>>
>> So now ref returns are preserved and the mixin is self-contained (doesn't require imports from the outside).
>>
>> Compared to my solution, this has the advantage that if the child defines a method, it will take precedence over the formatted one. So that allowed me to add a feature: if no methods are specified, all are forwarded.
>>
>> There are a couple of ways in which this could and should be improved, most notably overloads control. Even as is it's pretty darn awesome, Meta could you please make it into a pull request? I think it should go in std.functional.
>>
>>
>> Andrei
>
> I have forgotten to mention that I will make a pull request for this ASAP. I have been in the process of moving and starting a new job this week and last so I only have enough time to occasionally post currently.

http://forum.dlang.org/post/mqnhhbbyctwrfzvbrocg@forum.dlang.org