www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - RFC: dispatchToMember 2, electric boogaloo

reply "Meta" <jared771 gmail.com> writes:
I've finally got around to fixing some bugs that were blocking 
dispatchToMember, and I've now got a working solution that's 
ready for destruction. Something I remember Andrei mentioning was 
controlling overloads, which I have not implemented and will 
significantly complicate the implementation. That bridge can be 
crossed once all the more trivial issues are ironed out.

https://github.com/MetaLang/phobos/commit/f31752c70dc56ca0b7bd963e891346942964a806

Please destroy.
Aug 13 2015
parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 14 August 2015 at 03:55:13 UTC, Meta wrote:

 I've finally got around to fixing some bugs that were blocking 
 dispatchToMember, and I've now got a working solution that's 
 ready for destruction. Something I remember Andrei mentioning 
 was controlling overloads, which I have not implemented and 
 will significantly complicate the implementation. That bridge 
 can be crossed once all the more trivial issues are ironed out.

 https://github.com/MetaLang/phobos/commit/f31752c70dc56ca0b7bd963e891346942964a806

 Please destroy.


Link to previous thread:

http://forum.dlang.org/thread/mi3pip$22va$1 digitalmars.com
Aug 13 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/13/15 11:59 PM, Meta wrote:

 On Friday, 14 August 2015 at 03:55:13 UTC, Meta wrote:

 I've finally got around to fixing some bugs that were blocking
 dispatchToMember, and I've now got a working solution that's ready for
 destruction. Something I remember Andrei mentioning was controlling
 overloads, which I have not implemented and will significantly
 complicate the implementation. That bridge can be crossed once all the
 more trivial issues are ironed out.

 https://github.com/MetaLang/phobos/commit/f31752c70dc56ca0b7bd963e891346942964a806


 Please destroy.


 Link to previous thread:

 http://forum.dlang.org/thread/mi3pip$22va$1 digitalmars.com


Nice work, though I see it fails to compile if the member does not 
define the member. I noticed sometimes "dispatchToMemberIfPresent" is 
useful, too, and allows for flexible composition and good introspection. 
So having both would be great.

Andrei
Aug 14 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 14 August 2015 at 14:29:38 UTC, Andrei Alexandrescu 
wrote:

 Nice work, though I see it fails to compile if the member does 
 not define the member. I noticed sometimes 
 "dispatchToMemberIfPresent" is useful, too, and allows for 
 flexible composition and good introspection. So having both 
 would be great.

 Andrei


"forwardIfDefined" does sound useful. My reasoning for erroring 
out is that failure is otherwise silent and possibly hard to 
debug. Having this behaviour be opt-in is certainly useful in 
some cases though, such as with std.allocator.

I also plan to detect whether the symbol being forwarded to is a 
function or a field, and generate an  property wrapper as 
appropriate, which shouldn't be too hard. What *will* be 
difficult, though, is controlling which overloads are forwarded 
to. Currently dispatchToMember just picks the first function that 
matches the name given. What did you have in mind for choosing 
overloads? I've thought about maybe having a small DSL that 
allows for choosing overloads, but that could be complicated and 
not worth the complexity.
Aug 14 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/14/15 10:38 AM, Meta wrote:

 I also plan to detect whether the symbol being forwarded to is a
 function or a field, and generate an  property wrapper as appropriate,
 which shouldn't be too hard.


Great.


 What *will* be difficult, though, is
 controlling which overloads are forwarded to. Currently dispatchToMember
 just picks the first function that matches the name given. What did you
 have in mind for choosing overloads? I've thought about maybe having a
 small DSL that allows for choosing overloads, but that could be
 complicated and not worth the complexity.


That's a toughie. Perhaps you don't support overloads in the first 
iteration. The best solution would be to define the same overloads in 
the client as they are in the member. That's technically very different 
from what you have now.

Closer to the current approach would be to define the template, and 
inside redo the overloading rules (hard). An easier/imperfect solution 
would be to just issue an error when two parameter sets fit.


Andrei
Aug 14 2015
prev sibling parent "Meta" <jared771 gmail.com> writes:
As an aside, forwardIfDefined seems like it would fit nicely in 
this mythical std.idioms module that's talked about from time to 
time.
Aug 14 2015