Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
"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:
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).
