Fully dynamic d by opDotExp overloading

[Don]

Nick Sabalausky wrote:
> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
> news:op.usjnzajzeav7ka at steves.networkengines.com...
>> On Fri, 17 Apr 2009 14:32:07 -0400, Nick Sabalausky <a at 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.