Fully dynamic d by opDotExp overloading

[Nick Sabalausky]

"Christopher Wright" <dhasenan at gmail.com> wrote in message 
news:gsaver$2ini$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> "davidl" <davidl at nospam.org> wrote in message 
>> news:op.usje9ia3j5j59l at my-tomato...
>>> The benefit is you don't need to write the call function,
>>
>> ...But you do have to write the opDotExp() function. How is that less 
>> work than just writing a dispatch function?
>
> It's more work, but it lets you do other interesting things.
>
> Prime example is one I mentioned earlier. Let's say we also get full RTTI 
> implemented soon (either in a library [I'm working on it] or in the 
> compiler). Then you can write a Variant type that you can call arbitrary 
> methods on. Neat, huh?
>
> Let's say you integrate D with a scripting language where you can add 
> methods to an object at arbitrary times. Instead of writing:
> scriptObj.invokeMethod("methodname", arguments);
>
> You can instead write:
> scriptObj.methodname(arguments);
>
> This is a library type which has no business knowing about any methods 
> that you have defined on scriptObj. Moreover, the alternative is to write 
> this:
>
> template ScriptMethod(string name)
> {
> enum ScriptMethod = "void " ~ name ~ "(...) { return 
> _vm.invokeMethod(_obj, \"" ~ name ~ \"" ~, _arguments, _argptr); }";
> }
>
> class ScriptObjWrapper
> {
> // repeat this a few dozen times for each method
> mixin (ScriptMethod!("methodname"));
> }
>
> It's syntactic sugar, but it's really neat.

Brainfuck and AppleScript are really neat, but I wouldn't want to write an 
app in either of them ;)

But anyway, like I've said before, syntactic sugar is fine, but this is 
syntactic sugar that undermines the programmer's ability to rely on 
compile-time checking of class members. "But only for the classes that use 
it." No, it undermines that trust across the board because it's non-obvious 
what classes are using it, so you'd have to always be on guard. "Operator 
overloading blah blah blah" That only causes problems when it's used *and* 
abused by a class, while this would cause problems *any* time it's used. Etc 
etc...