Fully dynamic d by opDotExp overloading

[Benji Smith]

Danny Wilson wrote:
> Now let's go from that obvious observation to opDotExp()
> 
> You know the class uses opDotExp() because it said so in the docs. 
> Examples that could really benifit from this are:
> - XMLRPC and other kinds of remoting
> - Quick access to: XML / JSON / Yaml / Config files / DB access
> - Calling DLLs without bindings
> - Lots more
> 
> All these would mention it in their docs, guaranteed. Because they use 
> opDotExp it's implicitly mentioned. I don't think anyone would tell a 
> documentation generator to list all public methods except opDotExp .. 
> that would be just braindead. And you could generate the docs yourself 
> if you have to code..

Incidentally, one ugly problem with using opDotExp is that the 
underlying invocation might allow characters that aren't legal in D 
identifiers.

For example, let's say I have a dynamic object wrapping a JavaScript 
library, and I want to access a JQuery object. JavaScript allows the '$' 
character to appear in identifiers, and the JQuery people cleverly used 
that name for one of their core objects (which, I think, acts as an ID 
registry, or something like that).

So, this is a perfectly legal JQuery expression:

    var a = $("hello");

Using the opDotExp syntax, I'd ideally prefer to call it like this:

    auto a = js.$("hello");

But the compiler will reject that syntax, since '$' isn't a legal D 
identifier. Of course, in cases like that, we'll just use some sort of 
dynamic invocation method:

    auto a = js.invoke("$", "hello");

Which makes me think this whole discussion is kind of a waste of time, 
since every single implementation of opDotExp is going to end up 
delegating to a string-based dispatcher method anyhow.

THAT'S the really interesting discussion. In fact, I think I'll start a 
new topic...

--benji