Clay language

[Adam Ruppe]

Andrej Mitrovic wrote:
> Actually, D is equipped to solve even that problem

Indeed.

Though, that doesn't cover all the uses of shuffling things around.
My oauth.d module currently still includes some of my own specific
app, like my own api secret. (It was originally hard coded, then I
moved it to a helper function, but the helper function is still in
the generic module instead of moved out.)

It looks like this:

oauthRequest(struct OAuthParams, request details...);

immutable myAppParams = OAuthParams("api key", "api secret", other);


In user code:

oauthRequest(myAppParams, ...);


Soon, I'll cut and paste that myAppParams out and move it to the
app-specific config.d, making oauth.d itself fully generic.


If I was using all fully qualified names, even if renamed:


oauth.oauthRequest(oauth.myAppParams, ...);

And I'd then have to change all that usage to:

oauth.oauthRequest(config.myAppParams, ...);



Relatively minor in this situation - at least it would tell me at
compile time that oauth.myAppParams no longer exists, so it is an
easy fix, but you can see how this could become very annoying as
the usage grows.