On Wed, 29 Dec 2010 14:40:31 +0000 (UTC)
Adam Ruppe <[email protected]> wrote:
> > (Name qualification in code, I mean at use place, is best used for
> > std or third-party lib, I guess.
>
> I don't see a difference between the two. If the source module
> matters, it matters if it is third party or not. If it doesn't
> matter, well it just doesn't matter!
Your argumentation seems to mix two (related but distinct) features:
* Explicite import at import place.
import std.stdio : writeln;
* Name qualification at use place
std.stdio.writeln("foo");
(When you use the first one, the second one is facultative, indeed.)
I am argumentating for the first feature but your replies (and replies from
others) often seem to imply I was preeching (which I don't, i'm not fan of Java
at all). I think we both agree the qualification idiom is a good thing when it
helps clarity, meaning names make sense.
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. (Surely I sadly miss the seventh divination sense of talented programmers.)
About your reply above, when using your own toolkit or domain-specific module,
semantic or conceptual relations with what your code is doing usually are more
obvious:
import myParsingLib : Literal, Klass, Choice, Sequence;
// expression parser
auto dot = new Literal(".");
auto digit = new Klass("0-9");
...
Qualification would often be kind of over-specification.
This is different from using general-purpose libs like for handling files:
here, proper qualifiers are often a true semantic hint on what an instruction
copes with. Also names of funcs, types, constants, are often very similar (if
not identical) in various general-purpose libraries. (Think at write*,
read*,...)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
