Clay language

[Andrej Mitrovic]

On 12/29/10, spir <denis.spir at gmail.com> wrote:
> It is wrong for me to make implicite import-all the default scheme. I cannot
> imagine how/why you do not see the huge documentation benefit of listing
> your toolkit at the top a module. Also, I do not understand how I'm supposed
> to guess where a func comes from if nothing in the importing module tells it
> to me.

Like Walter said, D offers measures against function hijacking and
that was the biggest problem with implicit import-all. D still offers
features like static import and selective import, so if someone wants
to take advantage of those to make the code more readable, they *can*.

In the end it's up to the programmer to choose. D has many options to
keep everyone happy.
Personally, I start writing some tryout code by importing modules as normal:

import std.range;
import std.algorithm;
{ ... test some code..
}

And then when I've figured out a good set of symbols that I need I add
a colon and list them:

import std.range : retro;
import std.algorithm : reduce, reverse;

But I really don't see the benefit of changing the semantics of
import. You won't get shot in the foot since D offers good protection
from function hijacking.

But even if you did change the semantics of import to a static import,
you still wouldn't fix the *programmers* themselves. Everyone will
simply start using /import module.*/, or /import module.all/ instead
of using the safe default /import module/ which would be a static
import. No defined default or convention in the community can force
programmers to code in one way.

And if you doubt that, just take a look at all the Python code that's
out there. A ton of programmers still use the star syntax to import
every symbol into the current scope, even though its frowned upon by
the Python community (and afaik you can't use it anymore in Python 3).
But D has counter-measures which prevent hijacking, and hence it's
pretty safe to simply import the whole module without worrying too
much.

As for figuring out where each symbol comes from, if it's your own
codebase you'll probably use the colon syntax if you're really having
problems figuring out where the symbols are coming from. Otherwise in
larger codebases you'll more than likely use some capable IDE or a
plugin that knows where each symbol comes from and lists them for you.

Otherwise I don't know what this discussion is about anymore. :)