在 Sat, 18 Apr 2009 03:26:13 +0800，Steven Schveighoffer
<schvei...@yahoo.com> 写道:
On Fri, 17 Apr 2009 15:08:12 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Nick Sabalausky wrote:
"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message
news:op.usjnzajzeav...@steves.networkengines.com...
On Fri, 17 Apr 2009 14:32:07 -0400, Nick Sabalausky <a...@a.a> wrote:
My main concern that I've read so far is how if a class has a dynamic
method dispatcher that's callable like a method, you can't rely on
the compiler to help you typecheck (or spellcheck) the *non-dynamic*
methods, because it will just default to sending incorrectly typed
data or misspelled methods to the dynamic dispatcher.
That is a *very* good point, that hadn't even occured to me.
I think dynamic methods have a very limited use, and probably aren't
worth polluting the D language for a few rare cases.
Agreed.
When you know the API ahead of time, you're almost always better off
to have statically typed objects. When you don't know it ahead of
time, well, I prefer the uglyness of seeing the quoted strings to
having the compiler just start trusting everything I do ;)
Agreed.
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.
If anything, this agreed-fest shows that the rift between static typing
and dynamic typing is alive and well. I've seen many discussions in
which people were mystified how anyone gets anything done in a
statically-typed OO language. (In fairness, static typing and OO have
at best a tense marriage.)
But anyway, my point is that it's good to be open-minded. If this
conversation does nothing but leave us firmly with our heels in
static-land, then we haven't gained anything. If we weren't used to
static types we wouldn't be here. 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. I suggested Walter since a long
time ago to support opDot!(string). He implemented the useless version
(sigh) which was arguably much simpler and offered a cheap way to
experiment. So I'm very happy it's back on the table, and with an
implementation to boot. Congratulations David.
I guess I don't mind the dynamic lookup of methods, but I really don't
like the proposal to make it look exactly like a statically typed call.
To "hide" the fact that you are doing a dynamic lookup makes me worry
about losing the invariants that I come to enjoy with statically typed
methods, that is, if I see x.method(a, b, c), it means that the compiler
has checked that I called that method correctly with the correctly typed
information.
I use C#'s runtime introspection all the time, and it makes for some
really awesome code (things I wish D could do), but I still have to do
things like
Type[] argTypes = ...;
object[] args = ...;
x.GetType().GetMethod("myMethod", argTypes).Invoke(x, args);
To have that simply cut down to:
x.myMethod(a, b, c);
That's exactly what opDot can be capable of accomplishing. GetMethod is
something which feeds the classobject with the method name the opDot woud
like to handle and the fingerprint of the function.
is a nifty experiment, but now I lost all ability to know how the
compiler is interpreting that. I bet D can do a much better job at
runtime type information than C# due to the template system being so
powerful, but I still want to know that I'm dynamically doing something
versus statically.
Something like:
void foo(object x)
{
x.invoke("myMethod", a, b, c);
}
where invoke is some method that uses the classinfo of x to look up the
method would be freaking awesome ;)
This can also be done in D2 with my opDot proposal.
-Steve
--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
