Fully dynamic d by opDotExp overloading

Don nospam at nospam.com
Fri Apr 17 10:17:55 PDT 2009


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.




More information about the Digitalmars-d mailing list