Fully dynamic d by opDotExp overloading

[Nick Sabalausky]

"Don" <nospam at nospam.com> wrote in message 
news:gsbovk$nbj$1 at digitalmars.com...
> 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.

Ok, now *that* is something I can be happy with.