On Fri, 17 Apr 2009 14:32:07 -0400, Nick Sabalausky <a...@a.a> wrote:
"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.
This is what I was talking about, but didn't thoroughly explain when I
said "ease of tracing where a method call goes."
Thanks for explaining this better.
I do see usefulness in cases like setting a field in a database row (which
should be relatively painless, path-wise). However, my preference is to
create a wrapper class around the row to have the compiler to type check
my calls. In that case, the typechecked version would just call a
dispatch routine anyways (which can be ugly because it's hidden). I think
dynamic methods are just asking for trouble in the form of latent bugs.
My main concern that I've read so far is how if a class has a dynamic
method dispatcher that's callable like a method, you can't rely on the
compiler to help you typecheck (or spellcheck) the *non-dynamic* methods,
because it will just default to sending incorrectly typed data or
misspelled methods to the dynamic dispatcher. I think dynamic methods
have a very limited use, and probably aren't worth polluting the D
language for a few rare cases. When you know the API ahead of time,
you're almost always better off to have statically typed objects. When
you don't know it ahead of time, well, I prefer the uglyness of seeing the
quoted strings to having the compiler just start trusting everything I do
;)
-Steve
