"Don" <nos...@nospam.com> wrote in message news:gsbovk$nb...@digitalmars.com... > davidl wrote: >> ÔÚ Sat, 18 Apr 2009 03:45:43 +0800£¬Nick Sabalausky <a...@a.a> дµÀ: >> >>> "Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message >>> news:gsak2p$1s8...@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.
