Fully dynamic d by opDotExp overloading

[Don]

Andrei Alexandrescu wrote:
> Nick Sabalausky wrote:
>> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
>> news:gsak2p$1s8a$1 at digitalmars.com...
>>> 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.
>>>
>>> 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.
>>>
>>
>> That's a separate issue. I absolutely agree with the usefulness of 
>> being able to invoke static methods via a string identifier at 
>> runtime. But I think opDotExp is an extremely flawed way to do it. A 
>> much better way would be through a reflection mechanism:
>>
>> class Foo
>> {
>>     void bar() {}
>> }
>>
>> auto foo = new Foo();
>> traits(foo).func("bar").invoke();
>>
>> That way, you can have the benefits of 
>> runtime-string-identifier-invocation (and have it on *every* 
>> class/method), but without completely loosing compile-time checking on 
>> the members of every class which is capable of using it.
> 
> I was expecting this objection. I think it's not based because unifying 
> syntax is a major part of adding such a feature. If we get to dynamic 
> invocation but we can't go the last mile, we failed. Look at 
> IDispatch-based programming in C++ vs. interpreted languages.

I'd even say that this feature is 100% syntax sugar. It doesn't add 
anything we can't do already (in an ugly way).