Clay language

[Adam D. Ruppe]

> While you read a module code you don't know where the imported
> names it uses come from.

That's a feature. Let me give an example. I recently wrote an OAuth
implementation for my web app.

I started off by writing it all in one module, the one where it
was used. That was ok until I wanted to use it in a different module,
so I cut and pasted it to a different file, the shared util.d.

Compile, both modules now work. No need to edit the user code at all.

Next up I moved it from that grab bag of project specific utilities
to a generic oauth.d module, refactoring it to be generic.

Add "import oauth;" and compile. All modules work without editing
their code. Later, I might choose to rename it to something more
generic. If I added another web mechanism, I might call it webauth.d
or something like that. Aside from the import lines, the rest of
the user code would confidently remain unchanged.


That's the advantage a good import system like D has. You can
make changes with ease and confidence knowing it isn't going to
break anything anywhere else. That's really the goal of modularity:
making it so a change in one place won't break code anywhere else.

Using fully qualified names works /against/ that.

(Note though that sometimes fully qualified names do make things
more clear or show something special about that block of code. They
have their uses and it makes me very happy D supports it and has
static imports. But their uses are more specialized: being the
default would be a net negative, for the reasons above.)