Fully dynamic d by opDotExp overloading

[Don]

davidl wrote:
> ÔÚ Sat, 18 Apr 2009 03:45:43 +0800£¬Nick Sabalausky <a at a.a> дµÀ:
> 
>> "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:
>>
> 
> The opDot func can be extremely restrictive by looking up a former added 
> table which are function fingerprints registered by a method call like 
> dynamo.addMethod("myfunc", &myfunc);
> dynamo.Lenght or dynamo.mymethud would just result runtime exception, 
> because you didn't register these functions.

The problem is a lack of notification at compile time. Runtime 
exceptions are the problem, not the solution.

By the way, if the opDot is a template (per Andrei's suggestion), then 
if it is marked as nothrow, you have a guarantee that if it compiles, 
it's valid.
nothrow opDot(char [])(args...) doesn't have any of the problems which 
Nick et. al have mentioned.