Fully dynamic d by opDotExp overloading

[davidl]

在 Fri, 17 Apr 2009 23:34:37 +0800，Steven Schveighoffer  
<schveiguy at yahoo.com> 写道:

> 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

Actually in a lot cases, you don't have the time to write the static  
wrapper.
Also for a COM object, you don't want to call it in such ways:

comobj.callfunc("ComObjFunc", 3,4,5);

You probably want to call it only by comobj.ComObjFunc(3,4,5);

Yes static wrapper can solve these all. Problem is not in all cases you  
want to make a static binding for it.


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/