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
