Fully dynamic d by opDotExp overloading

[Nick Sabalausky]

"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?

> you don't need to write the string quote.

I think I'd prefer that. If I put something in quotes, that tells me that 
typos might not get detected until runtime. But if I don't use quotes, and 
it compiles, then I know it's ok. With opDotExp, that certainty goes right 
out the window. All of a sudden I never know if an identifier following a 
dot compiled because it's ok, or because the error detection has been 
deferred. I'd feel like I was working in a dynamic language and I *HATE* 
working with dynamic languages. It's like trying to construct a building on 
a patch of ground that you know at any moment could change into a lake, 
sand, cliffside, or simply cease to exist without any warning.

Additionally, here's an example from Haxe's xml.Fast:

page.node.html.node.head.node.title.x.addChild(Xml.createPCData("Hello"));

Think fast without any close inspection: What's the path being used? Umm...

Ok, without opDotExp, that would be:

page.node("html").node("head").node("title").x.addChild(Xml.createPCData("Hello"));

That's a hell of a lot easier to read. Very easy now to see, at a mere 
glance, the path is "html/head/title".

Of course, you could adjust the API for the Haxe/opDotExp version to be more 
like:

page.html.head.title.x.addChild(Xml.createPCData("Hello"));

But now (in addition to still not having the certainty of "if an unquoted 
identifier compiles, it must be ok"), you've opened yourself up to a world 
of naming collision issues.