"davidl" <dav...@nospam.org> wrote in message
news:op.usje9ia3j5j...@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.
