Op Fri, 17 Apr 2009 22:31:04 +0200 schreef Nick Sabalausky <a...@a.a>:
But with opDotExp, its mere *existence* undermines my ability to be sure
that non-quoted identifiers are ok as long as they've compiled. That
type of
tradeoff is obviously fine when the potential benefits are significant
enough (operator overloading, for instance). But from everything I've
seen
so far, opDotExp's benefits are trivial at best. I don't want to have to
keep track of "ok, is this class using opDotExp or not, because if it is,
then I need to be more careful", just for the sake of a feature that
provides such a tiny and questionable benefit.
class AbstractConceptInvoker
{
public void activate(){}
}
auto a = new AbstractConceptInvoker();
a.activate();
What does my code do? Who knows? It could connect to a DB and delete all
tables. It could be an O(infinity) operation...
You have no idea until you either read (correct) documentation about it,
or look at the code.
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..
So what exactly are you afraid of?!
