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.
That's the VB/PHP nightmare -- allow any garbage to compile.
Yet, if the function name is in a template (which I believe it has to
be), the problem isn't as bad: you can detect it in many cases.
The only use case I can really see for this is when an extremely large
number of functions need to be created. Swizzling an array was one
example that was mentioned previously:
float4 f, g;
g = f.wzyx * f.zzxy;
If you were to create all possibilities, it's 4^4 = 256 function
overloads. Which is too many to document, but is still feasible to
create with a mixin. If it was instead 8^8 functions, it'd really be a
lot easier on the poor compiler's symbol table to have the functions
generated only on demand.
Still,
g = f.swizzle!("wzyx");
(or Andrei-style g = f.swizzle!"wzyx"; )
isn't so terrible.
D is already incredibly more flexible and powerful than (say) C++, so
there's not going to be any use cases which go from terrible to perfect.
I think dynamic methods have a very limited use, and probably aren't
worth polluting the D language for a few rare cases.
Agreed.
If there were a few use cases which were sufficiently important, it
might be possible to create a solution for them which didn't allow so
much undesirable behaviour.
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.
Yeah, The ideal language would detect ALL bugs at compile time. We don't
want to move in the wrong direction.
