Fully dynamic d by opDotExp overloading

[Don]

Steven Schveighoffer wrote:
> On Fri, 17 Apr 2009 11:27:57 -0400, davidl <davidl at nospam.org> wrote:
> 
>> 在 Fri, 17 Apr 2009 23:20:53 +0800，davidl <davidl at nospam.org> 写道:
>>
>>> 在 Fri, 17 Apr 2009 22:24:04 +0800，Steven Schveighoffer 
>>> <schveiguy at yahoo.com> 写道:
>>>
>>>> On Fri, 17 Apr 2009 09:44:09 -0400, Leandro Lucarella 
>>>> <llucax at gmail.com> wrote:
>>>>
>>>>> I don't fully understand the example though. In writefln((v.qq = 
>>>>> 5).i),
>>>>> how is that B.i is assigned to 5 if the opDotExp("qq", 5) don't 
>>>>> propagate
>>>>> the 5 to the new B()?
>>>>
>>>> I think it translates to
>>>>
>>>> opDotExp("qq") = 5
>>>>
>>>> Without knowing the signature of qq, how is the compiler supposed to 
>>>> infer that it is a property?  In fact, I think this might be a 
>>>> limitation of this syntax, you can't define dynamic properties.
>>>>
>>>> I for one, can't really see a huge benefit, but then again, I don't 
>>>> normally work with dynamic-type langauges.  It looks to me like a 
>>>> huge hole that the compiler will ignore bugs that would have been 
>>>> caught if the methods were strongly typed:
>>>>
>>>
>>> Actually this can help ddl project to work more nicely. Consider you 
>>> can call plugin code directly without static bindings. And I believe 
>>> delphi COM variant use some similar trick. It allows you call COM 
>>> object without static bindings. Sometimes it's troublesome to get the 
>>> static bindings, and you only need one piece of little function(you 
>>> won't need the whole interface).
>>>
>>>
>>
>> DDBI can also benefit from it.
>>
>> Consider the use case:
>> myRow.Col1 = "abc";
> 
> Yes, this case does make sense, but I would still probably rather write 
> a statically-typed wrapper.
> 
> Plus it's not terribly hard to write:
> 
> myRow.set("Col1", "abc");
> 
> I'm not yet convinced, but it remains to be seen if there is some killer 
> functionality that cannot be had without it.
> 
> -Steve

I believe it is entirely syntax sugar. It's no different to:

foo(char [] funcname, T...) (T args){}

But it allows you to eliminate the foo!("funcname")(args) with 
funcname(args).  Which is a _very_ significant improvement.

BTW, I think it _must_ be done as a template, as Andrei suggested.
In the original, you have serious problems with delegates, for example, 
since the function being called has one more parameter (the function 
name) than it pretends to have.