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.
