Fully dynamic d by opDotExp overloading

[Steven Schveighoffer]

On Sun, 19 Apr 2009 10:42:19 -0400, Denis Koroskin <2korden at gmail.com>  
wrote:

> On Sun, 19 Apr 2009 18:26:11 +0400, Steven Schveighoffer  
> <schveiguy at yahoo.com> wrote:
>
>> On Sun, 19 Apr 2009 06:26:57 -0400, Denis Koroskin <2korden at gmail.com>  
>> wrote:
>>
>>> On Sun, 19 Apr 2009 05:40:32 +0400, Steven Schveighoffer  
>>> <schveiguy at yahoo.com> wrote:
>>>
>>>> On Sat, 18 Apr 2009 21:10:27 -0400, Andrei Alexandrescu  
>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>
>>>>> Adam Burton wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>>> What about using something like '->' for dynamic calls instead of  
>>>>>>>> '.'?
>>>>>>> That's absolutely useless. If I have to write anything different  
>>>>>>> from
>>>>>>> "." I might as well write "bloodyMaryBloodyMaryBloodyMary".
>>>>>>>
>>>>>>> Andrei
>>>>>> You could even write 'noodles' but that doesn't really give me a  
>>>>>> reason as to why it's absolutely useless. Please clarify, I thought  
>>>>>> it seemed like a reasonable idea, if it isn't I would like to know  
>>>>>> why.
>>>>>
>>>>> I apologize for the snapping. There's no excuse really, but let me  
>>>>> mention that this thread has been particularly meandering.
>>>>>
>>>>> The point of using "." is not syntactic convenience as much as the  
>>>>> ability of the Dynamic structure to work out of the box with  
>>>>> algorithms that use the standard notation.
>>>>
>>>> Hm... the thought just occurred to me.
>>>>
>>>> At what time are you going to use opDotExp so an entity be used in an  
>>>> algorithm rather than actually defining the functions directly?  For  
>>>> example, if you want to make a class/struct a range, why not just  
>>>> define the functions directly?  It seems odd to define them using  
>>>> opDotExp.
>>>>
>>>
>>> Variant variantRange = someRange();
>>> foreach (element; variantRange) {
>>>     // ...
>>> }
>>>
>>> Variant forwards all the front/back/etc methods to an underlying range.
>>
>> Doesn't the current opDot solution do this?  Forwarding all calls to a  
>> certain member is not a really compelling argument for changing opDot  
>> to allow dynamic method names.
>>
>> -Steve
>
> opDot is reprecated (use alias this instead) and will be eventually  
> removed.
>
> But "alias this" is quite unsafe because it exposes the inner data  
> (which is supposed to be hidden in some case, think of reference  
> counting wrapper - you never want to give raw access to an underlying  
> data).
>
> Besides, there are is a use-cases that you can't implement in a way  
> other than opDotExp. For example, add some logging or profiling:
>
> struct Profile(T)
> {
>     private T inner;
>
>     auto opDotExp(string name, T...)(T args)
>     {
>         profiler.enter(name);
>         scope(exit) profiler.leave();
>
>         return <forward a call to 'inner' - how one would do  
> this?>(args);
>     }
> }
>

Yes, there are many things that opDotExp can do that opDot or alias this  
(which is essentially opDot without any code).  Hooking every function  
call on a type seems to be one of the two killer use cases of this feature  
(the other being defining a large range of functions from which only a  
small number need to exist).  But call forwarding seems not to be one of  
them.  There are better ways to simply forward a call (such as in your  
variant example).

I'm pretty convinced that this is a useful feature, I still have qualms  
about how it's really easy to define a runtime black hole where the  
compiler happily compiles empty functions that do nothing instead of  
complaining about calling a function that does not exist.

Also, I don't think the requirement for this feature needs to be for the  
arguments to be templated, it should be sufficient to have a single string  
template argument.  This way, you can overload opDotExp functions via  
argument lists.

And BTW, the answer to your question above I think:

mixin("return inner."~name~"(args)");

Andrei demonstrated this usage in his Pascalize example.

-Steve