Fully dynamic d by opDotExp overloading

[Steven Schveighoffer]

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.

>
>> 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.

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?

>
>> 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