Fully dynamic d by opDotExp overloading

[Steven Schveighoffer]

On Fri, 17 Apr 2009 14:32:07 -0400, Nick Sabalausky <a at a.a> wrote:

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

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