digitalmars.D.learn - How to dispatch a class function for an object accessed by handle?
- wjoe (45/45) Mar 05 2020 Consider a Factory that creates instances of various different
- Steven Schveighoffer (18/20) Mar 05 2020 You could do it with delegates. But it's ugly:
- wjoe (6/26) Mar 05 2020 I have an ugly implementation with a one liner mixin and I don't
- Adam D. Ruppe (36/38) Mar 05 2020 Why do you need an `alias fn` like that?
- wjoe (9/50) Mar 05 2020 Thanks for your reply:)
- wjoe (18/30) Mar 06 2020 Follow-up question:
- Adam D. Ruppe (29/33) Mar 06 2020 I.... don't know. It works if you rename the inner one but it
- Steven Schveighoffer (15/56) Mar 06 2020 This doesn't work, because an eponymous template does not provide access...
- Steven Schveighoffer (7/8) Mar 06 2020 I realized, this doesn't work. Because f.opDispatch is a `this` call,
- Adam D. Ruppe (18/20) Mar 06 2020 oh yikes, how did I not notice that?!
- Steven Schveighoffer (13/29) Mar 06 2020 Do this instead, I think this will work and avoids an extra call (and
- Steven Schveighoffer (3/4) Mar 06 2020 And obviously, this should be opDispatch with a capital D !
- wjoe (15/35) Mar 06 2020 This isn't the worst thing to use and since it's just for testing
- Adam D. Ruppe (4/11) Mar 06 2020 ooh you can do that. on the alias, use __traits(identifier) to
- wjoe (3/14) Mar 06 2020 Awesome! I read the docs up and down but I couldn't figure it
- wjoe (14/73) Mar 06 2020 I tried Instantiate this morning after I found a reply you made
Consider a Factory that creates instances of various different resource object instances, all of which have a common interface, and returns a handle to them. class Factory { struct Handle{} Handle create(R: Resource, ARGS...)(ARGS args) { auto r = new R(args); //... return handle; } } auto f = new Factory; auto wallpaperhandle = f.create!Bitmap(...); In order to be able do something with these resources there's a function to get the resource instance from a handle: auto get(R: Resource)(Handle h) {...}; auto bitmap = f.get!Bitmap(wallpaperhandle); auto size = bitmap.getSize(); if (condition) bitmap.scaleByFactor(2); I don't like this approach because it exposes the instance directly. What I want instead is something like this auto size = f.dispatch!(Bitmap, Bitmap.getSize)(wallpaperhandle); if (condition) f.dispatch!(Bitmap, Bitmap.scaleByFactor)(wallpaperhandle, 2); Implement this for free functions i would do something like this void dispatch(alias fn, ARGS...)(Handle handle, ARGS args) { fn(handle, args); } but how can I call fn in the context of an object instance? class Factory { auto ref dispatch(R: Resource, alias fn, ARGS ...)(Handle handle, ARGS args) { auto r = get!R(handle); assert(stuff is valid); return r.fn(args); // How can I call class function 'fn' using r ? } } mixin(something) comes to mind, but are there better options ?
Mar 05 2020
On 3/5/20 9:24 AM, wjoe wrote:but how can I call fn in the context of an object instance?You could do it with delegates. But it's ugly: import std.stdio; class C { void foo() { writeln("Yup");} } void main() { alias f = C.foo; auto c = new C; void delegate() dg; dg.funcptr = &f; dg.ptr = cast(void*)c; dg(); // prints "Yup" } I don't know of a way to call f with c aside from this. -Steve
Mar 05 2020
On Thursday, 5 March 2020 at 14:46:24 UTC, Steven Schveighoffer wrote:On 3/5/20 9:24 AM, wjoe wrote:I have an ugly implementation with a one liner mixin and I don't like it. Your solution looks interesting but I think that's more code than my current solution. Thanks for your reply though.but how can I call fn in the context of an object instance?You could do it with delegates. But it's ugly: import std.stdio; class C { void foo() { writeln("Yup");} } void main() { alias f = C.foo; auto c = new C; void delegate() dg; dg.funcptr = &f; dg.ptr = cast(void*)c; dg(); // prints "Yup" } I don't know of a way to call f with c aside from this. -Steve
Mar 05 2020
On Thursday, 5 March 2020 at 14:24:33 UTC, wjoe wrote:Implement this for free functions i would do something like this void dispatch(alias fn, ARGS...)(Handle handle, ARGS args)Why do you need an `alias fn` like that? My suggestion would be to just use the `opDispatch` magic method that gives you a string, then `__traits(getMember, obj, memberName)(args)` to call it. But if you specifically need the alias param that won't work as well. (You could still do `__traits(getMember, obj, __traits(identifier, fn))` though, so it isn't ruled out entirely, just not as nice. That is also more likely to break with overloads btw) struct Handle { private Whatever obj; auto opDispatch(string name, Args...)(Args args) { return __traits(getMember, obj, name)(args); } } And the usage would look like: auto size = f.getSize(wallpaperhandle); assuming the Handle knows how to store Whatever without being told what it is again at the call site (e.g. if you actually use an `interface` internally, or an encapsulated tagged union or whatever). If you do need to tell it what it is, a two-level function gives that opportunity: template opDispatch(string name) { auto opDispatch(T, Args...)(Args args) { auto obj = cast(T) o; // or whatever you do to convert return __traits(getMember, obj, name)(args); } } then the usage looks like auto size = f.getSize!Bitmap(wallpaperhandle); 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. But it depends on what exactly you are doing.
Mar 05 2020
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:Thanks for your reply:) I don't need an alias at all. I was trying to figure something out with opDispatch first but something like __traits(getMember, obj, name)(args); never occurred to me. Awesome! The handle knows whether or not it's valid and where to find the object and it only makes sense in the context of the factory that made it. The template opDispatch looks like what I was looking for :)Implement this for free functions i would do something like this void dispatch(alias fn, ARGS...)(Handle handle, ARGS args)Why do you need an `alias fn` like that? My suggestion would be to just use the `opDispatch` magic method that gives you a string, then `__traits(getMember, obj, memberName)(args)` to call it. But if you specifically need the alias param that won't work as well. (You could still do `__traits(getMember, obj, __traits(identifier, fn))` though, so it isn't ruled out entirely, just not as nice. That is also more likely to break with overloads btw) struct Handle { private Whatever obj; auto opDispatch(string name, Args...)(Args args) { return __traits(getMember, obj, name)(args); } } And the usage would look like: auto size = f.getSize(wallpaperhandle); assuming the Handle knows how to store Whatever without being told what it is again at the call site (e.g. if you actually use an `interface` internally, or an encapsulated tagged union or whatever). If you do need to tell it what it is, a two-level function gives that opportunity: template opDispatch(string name) { auto opDispatch(T, Args...)(Args args) { auto obj = cast(T) o; // or whatever you do to convert return __traits(getMember, obj, name)(args); } } then the usage looks like auto size = f.getSize!Bitmap(wallpaperhandle); 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. But it depends on what exactly you are doing.
Mar 05 2020
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"); 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(...); ?
Mar 06 2020
On Friday, 6 March 2020 at 11:51:54 UTC, wjoe wrote:I don't understand this error message. Which type can't be resolved?I.... don't know. It works if you rename the inner one but it doesn't like eponymous templates like this. I suspect either the spec subtly doesn't allow it or a compiler bug. I think the type it is referring to is the `this` type. You can work around with an alias: // test rig import std.stdio; struct A { template opDispatch(string name) { auto opDispatch(T, Args...)(Args args) { writeln(name, ".", T.stringof, "(", args, ")"); } } } // workaround void main() { A a; alias helper = a.opDispatch!("foo"); a.helper!(int)(5, "omg"); } So the helper does one level, then the next level is done on the next line to avoid the stupid "multiple ! not allowed". You need to specify the `a` again to avoid `need this for...` due to how aliases are kinda weird. Huge hassle to use but if just doing it temporarily to debug it can be livable.Is there a way to look at output of what the compiler generates for f.whatever!SomeResource(...); ?-vcg-ast or something like to dmd but i never use it since there's TONS of spam in a file called `yourfile.d.cg`
Mar 06 2020
On 3/6/20 6:51 AM, wjoe wrote:On Thursday, 5 March 2020 at 18:33:41 UTC, Adam D. Ruppe wrote:This doesn't work, because an eponymous template does not provide access to the internals of the template.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");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
Mar 06 2020
On 3/6/20 8:55 AM, Steven Schveighoffer wrote:Instantiate!(f.opDispatch!fname, Bitmap)("path/to/wallpaper.png")I realized, this doesn't work. Because f.opDispatch is a `this` call, but is not called that way in this case. Adam's way doesn't work either, because the call doesn't use the alias, but just instantiates opDispatch with the new name! I think the only solution might be the mixin. -Steve
Mar 06 2020
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);
Mar 06 2020
On 3/6/20 9:14 AM, Adam D. Ruppe wrote:On Friday, 6 March 2020 at 14:05:55 UTC, Steven Schveighoffer wrote: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 } } -SteveAdam'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); } }
Mar 06 2020
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
Mar 06 2020
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: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.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);
Mar 06 2020
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.
Mar 06 2020
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:Awesome! I read the docs up and down but I couldn't figure it out. Thank you!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.
Mar 06 2020
On Friday, 6 March 2020 at 13:55:25 UTC, Steven Schveighoffer wrote:On 3/6/20 6:51 AM, wjoe wrote: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 Thursday, 5 March 2020 at 18:33:41 UTC, Adam D. Ruppe wrote:This doesn't work, because an eponymous template does not provide access to the internals of the template.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");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
Mar 06 2020