Fully dynamic d by opDotExp overloading

[davidl]

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

> On Fri, 17 Apr 2009 11:11:55 -0400, davidl <davidl at nospam.org> wrote:
>
>> 在 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.
>>>
>>
>> The opDotExp overload func is supposed to deal with that, because it's  
>> in your hand to deal with the dynamic properties. The example here is  
>> illustrating the dynamic properties.
>
> except, you can't define a property like:
>
> void prop(int x)
> {
>     _prop = x ^ ~0;
> }
>
> Using a dynamic method.
>

But if you want a dynamic property, you won't want to do it in that way.
You actually make the opDot to do:

void opDot(char[] methodname, ...)
{
   if (methodname = "prop")
   {
     // deal with the vararg to get the int x
     // assign it to _prop, then you're done.
     // or you can call the prop func here by reconstructing the vararg.
   }
}

Notice that if statement can be done by a delegate. Thus when you add a  
property you simply add your delegate func to the class. And opDot call  
those delegates one by one.

>>
>>> 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:
>>>
>>> class c
>>> {
>>>    void opDotExp(char[] methodname,...)
>>>    {
>>>       if(methodname == "mymethod")
>>>          callMyMethod();
>>>       else
>>>          throw new Exception("bad method name: " ~ methodname);
>>>    }
>>> }
>>>
>>> void foo(c myc, bool rarelySetToTrue)
>>> {
>>>    if(rarelySetToTrue)
>>>      myc.mymethud(); // compiles, will throw runtime exception
>>> }
>>>
>>
>> The problem is you're dealing with the class which is overloaded its  
>> opDot. You know the risk before hand, you are not going to overload for  
>> every classes. Here, you seem to little bit overrate this feature. :)
>> If you want things checked, then you probabely need to go back to  
>> static. This dynamic stuff is used for dynamic things only, and as long  
>> as you have to do it in the dynamic way that means you have no easy way  
>> or even impossible to check it at compiletime and you accept the  
>> potential risk like the example you posted.
>
> Sure, but what is the reason to need dynamic methods?  I'm just trying  
> to understand the usefulness of it.  If a method is dynamic, we lose the  
> following things:
>
> - compile-time type/signature checking
> - IDE assistance in determining which methods are available
> - ease of tracing where a method call goes.
> - not future proof -- for example, if a method name gets changed or  
> moved, the code using the method still compiles.
>

Yes, these problems can happen across plugins/host, database design/db  
apps. Host can't validate its plugins. Host doesn't know what plugins can  
provide. DB apps which I know don't have much fancy technics to be future  
proof (what if my db design changes? those SQL won't immediately fail at  
compile time, only when you run it.)

> If we lose all these things, there must be *something* we gain by doing  
> this, right?
>
> Also, what is the benefit of doing something like this versus  
> specifically calling the dispatcher instead of having the compiler  
> translate it?
>

The benefit is you don't need to write the call function, you don't need  
to write the string quote. Take a look at my other posts about the  
usecases of this proposal(ddl, ddbi).

>>
>>> Also, how do you overload the return value?  Using this proposal, you  
>>> can't have different dynamic methods that return different types.
>>>
>>
>> Umm, maybe make the compiler to pass the return type into the opDot  
>> would allow the opDot func to decide which overload func to call.
>
> Walter already has issues overloading on return type, I'm not sure this  
> is any different.
>
> -Steve

Actually different, Walter needs to modify the overload mechanism in the  
current compiler for different function finger prints. What I need to do  
is sending the return type to the opDot method. Because the overloading is  
done by the opDot func at runtime, so I don't have Walter's difficulty in  
dealing with overloading :D

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