Fully dynamic d by opDotExp overloading

[Steven Schveighoffer]

On Fri, 17 Apr 2009 15:08:12 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Nick Sabalausky wrote:
>> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message  
>> news:op.usjnzajzeav7ka at steves.networkengines.com...
>>> On Fri, 17 Apr 2009 14:32:07 -0400, Nick Sabalausky <a at a.a> wrote:
>>>
>>> My main concern that I've read so far is how if a class has a dynamic  
>>> method dispatcher that's callable like a method, you can't rely on the  
>>> compiler to help you typecheck (or spellcheck) the *non-dynamic*  
>>> methods, because it will just default to sending incorrectly typed  
>>> data or misspelled methods to the dynamic dispatcher.
>>  That is a *very* good point, that hadn't even occured to me.
>>
>>> I think dynamic methods  have a very limited use, and probably aren't  
>>> worth polluting the D  language for a few rare cases.
>>>
>>  Agreed.
>>
>>> When you know the API ahead of time,  you're almost always better off  
>>> to have statically typed objects.  When  you don't know it ahead of  
>>> time, well, I prefer the uglyness of seeing the  quoted strings to  
>>> having the compiler just start trusting everything I do  ;)
>>>
>>  Agreed.
>
> I think there's merit in binding via strings. It makes for very flexible  
> code that is future-proof, dynamic-linking-friendly, and hot-swappable  
> without recompiling (e.g. you don't need to recompile because you now  
> implement an interface etc.) Reflection is very useful as well.
>
> If anything, this agreed-fest shows that the rift between static typing  
> and dynamic typing is alive and well. I've seen many discussions in  
> which people were mystified how anyone gets anything done in a  
> statically-typed OO language. (In fairness, static typing and OO have at  
> best a tense marriage.)
>
> But anyway, my point is that it's good to be open-minded. If this  
> conversation does nothing but leave us firmly with our heels in  
> static-land, then we haven't gained anything. If we weren't used to  
> static types we wouldn't be here. I think D can and should allow string  
> lookup for its methods. It's a low-complexity proposition that adds a  
> very interesting tool to D's arsenal. I suggested Walter since a long  
> time ago to support opDot!(string). He implemented the useless version  
> (sigh) which was arguably much simpler and offered a cheap way to  
> experiment. So I'm very happy it's back on the table, and with an  
> implementation to boot. Congratulations David.

I guess I don't mind the dynamic lookup of methods, but I really don't  
like the proposal to make it look exactly like a statically typed call.   
To "hide" the fact that you are doing a dynamic lookup makes me worry  
about losing the invariants that I come to enjoy with statically typed  
methods, that is, if I see x.method(a, b, c), it means that the compiler  
has checked that I called that method correctly with the correctly typed  
information.

I use C#'s runtime introspection all the time, and it makes for some  
really awesome code (things I wish D could do), but I still have to do  
things like

Type[] argTypes = ...;
object[] args = ...;
x.GetType().GetMethod("myMethod", argTypes).Invoke(x, args);

To have that simply cut down to:

x.myMethod(a, b, c);

is a nifty experiment, but now I lost all ability to know how the compiler  
is interpreting that.  I bet D can do a much better job at runtime type  
information than C# due to the template system being so powerful, but I  
still want to know that I'm dynamically doing something versus statically.

Something like:

void foo(object x)
{
    x.invoke("myMethod", a, b, c);
}

where invoke is some method that uses the classinfo of x to look up the  
method would be freaking awesome ;)

-Steve