On 3/6/20 9:14 AM, Adam D. Ruppe wrote:
> On Friday, 6 March 2020 at 14:05:55 UTC, Steven Schveighoffer wrote:
>> Adam's way doesn't work either, because the call doesn't use the alias, but just instantiates opDispatch with the new name!'
> 
> oh yikes, how did I not notice that?!
> 
> so yeah just kinda screwed. I'd probably suggest at tis point having the opDispatch be a trivial implementation that just forwards to another named method.
> 
> struct A {
>    template opDispatch(string name) {
>       auto opDispatch(T, Args...)(Args args) {
>             return other_name!(name, T, Args)(args);
>       }
>    }

Do this instead, I think this will work and avoids an extra call (and having to do the argument plumbing that inevitably comes with this kind of wrapping):

template opDispatch(string name) {
   alias opdispatch(T) = other_name!(name, T);
}

template other_name(string name, T) {
   auto other_name(Args...)(Args args) {
      // real implementation
   }
}

-Steve

On 3/6/20 9:42 AM, Steven Schveighoffer wrote:
> alias opdispatch(T) = other_name!(name, T);

And obviously, this should be opDispatch with a capital D !


-Steve

On Friday, 6 March 2020 at 13:55:25 UTC, Steven Schveighoffer wrote:
> On 3/6/20 6:51 AM, wjoe wrote:
>> On Thursday, 5 March 2020 at 18:33:41 UTC, Adam D. Ruppe wrote:
>>> On Thursday, 5 March 2020 at 14:24:33 UTC, wjoe wrote:
>>>
>>> [...]
>>>
>>> template opDispatch(string name) {
>>>     auto opDispatch(T, Args...)(Args args) {
>>>        ...
>>>     }
>>> }
>>>
>>> [...]
>>>
>>>
>>> NOTE: opDispatch suppresses internal compile errors, it will just say "no such property whatever". you can explicitly instantiate with `f.opDispatch!"whatever` to help see better errors.
>>>
>> 
>> Follow-up question:
>> 
>> Calling f.whatever!SomeResource(...); works no problem.
>> However I can't figure out how to call a function by explicitly instantiating opDispatch.
>> 
>> Since f.opDispatch!"load"(handle, "wallpaper.png");
>> doesn't compile, I refreshed my memory about the shortcut syntax and the eponymous syntax and the way I read it is that this is a template of a template.
>> 
>> So I tried this: f.opDispatch!"load".opDispatch!Bitmap(handle, "path/to/wallpaper.png");
>
> This doesn't work, because an eponymous template does not provide access to the internals of the template.
>
>> 
>> But this doesn't compile either and errors out with:
>> Error: Cannot resolve type for f.opDispatch(T, ARGS...)(ResourceHandle handle, ARGS args)
>> 
>> I don't understand this error message. Which type can't be resolved?
>> 
>> Is there a way to look at output of what the compiler generates for f.whatever!SomeResource(...); ?
>
> You can use -vcg-ast, but this isn't necessarily going to be compilable code.
>
> D doesn't allow chained instantiation (i.e. (A!B)!C), so you need to use either a mixin or a helper:
>
> import std.meta;
>
> enum fname = "load";
>
> Instantiate!(f.opDispatch!fname, Bitmap)("path/to/wallpaper.png")
>
> or
>
> mixin("f." ~ fname ~ "!(Bitmap)(...);");
>
> I'm assuming fname is given to you as a compile-time string and that's why you'd need to run opDispatch manually.
>
> -Steve

I tried Instantiate this morning after I found a reply you made to someone else who was trying to chain instantiate. But for the reason you stated it didn't work.

Funny you mention: mixin("f." ~ fname ~ "!(Bitmap)(...);");
Because that's like my initial implementation :)

As for the the command line switch. My plan wasn't to copy paste. Sometimes I have a hard time to comprehend results because it's like I've put water, flour and eggs on the table. Then I'm presented with a loaf of bread and I'm baffled. Then I want to understand what happened between putting the ingredients on the table and the ready baked loaf.

Anyways, thanks for your answers.

On Friday, 6 March 2020 at 14:14:04 UTC, Adam D. Ruppe wrote:
> On Friday, 6 March 2020 at 14:05:55 UTC, Steven Schveighoffer wrote:
>> Adam's way doesn't work either, because the call doesn't use the alias, but just instantiates opDispatch with the new name!'
>
> oh yikes, how did I not notice that?!
>
> so yeah just kinda screwed. I'd probably suggest at tis point having the opDispatch be a trivial implementation that just forwards to another named method.
>
> struct A {
>   template opDispatch(string name) {
>      auto opDispatch(T, Args...)(Args args) {
>            return other_name!(name, T, Args)(args);
>      }
>   }
>
>   auto other_name(string name, T, Args...)(Args args) {
>       // real implementation
>   }
> }
>
>
> and then to test it externally you do
>
> a.other_name!("whatever", Bitmap)(args, here);

This isn't the worst thing to use and since it's just for testing it's fine.

I came up with a similar interface like a.other_name!("whatever", Bitmap)(args, here); after discarding .opDispatch() and I called the thing
 .dispatch(T, string fn, ARGS...)(...).

But didn't like the string part and that's when I introduced the alias fn because I figured maybe it's possible to do something like:
  factory.dispatch!(Bitmap.load)(handle, path);
and get the Bitmap part from that alias and hence save the duplicate Bitmap type in factory.dispatch!(Bitmap, Bitmap.load)(...);

Anyways thanks for your help.

On Friday, 6 March 2020 at 15:05:56 UTC, wjoe wrote:
> But didn't like the string part and that's when I introduced the alias fn because I figured maybe it's possible to do something like:
>   factory.dispatch!(Bitmap.load)(handle, path);
> and get the Bitmap part from that alias and hence save the duplicate Bitmap type in factory.dispatch!(Bitmap, Bitmap.load)(...);

ooh you can do that. on the alias, use __traits(identifier) to get thef ucntion name and __traits(parent) to get the class name! then it reduces to what we already wrote.

On Friday, 6 March 2020 at 15:19:39 UTC, Adam D. Ruppe wrote:
> On Friday, 6 March 2020 at 15:05:56 UTC, wjoe wrote:
>> But didn't like the string part and that's when I introduced the alias fn because I figured maybe it's possible to do something like:
>>   factory.dispatch!(Bitmap.load)(handle, path);
>> and get the Bitmap part from that alias and hence save the duplicate Bitmap type in factory.dispatch!(Bitmap, Bitmap.load)(...);
>
> ooh you can do that. on the alias, use __traits(identifier) to get thef ucntion name and __traits(parent) to get the class name! then it reduces to what we already wrote.

Awesome! I read the docs up and down but I couldn't figure it out. Thank you!