--- Comment #9 from David Simcha <> 2009-11-14 10:54:07 PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > IMHO the purpose of a module system is to stay the heck out of the user's 
> > way
> > and let the user get on w/ solving the real problem.  It should only make 
> > noise
> > when there's a real ambiguity.  Making imports unnecessarily verbose,
> > complicated, or fine-grained is just a bad idea.  D already deals well with
> > collisions.  When there's not a collision, I personally prefer to have stuff
> > "just work" without having to care that there are namespaces.
> What you say is good for *writing* code, but it's *really* bad for *reading*
> code and tracking dependencies. It's subject to highjacking too (in very, very
> weird and special cases, I'm aware of that ;).

As for reading code, I totally disagree.  Syntactic noise and unnecessary
verbosity makes code harder to read.

As far as dependency tracking,

1.  That's what IDEs are for.  If D gets off the ground, it will eventually
have a good IDE.
2.  What do you do more, write/read code or track dependencies?

A fundamental tenet of good interface design is that you should not have to
tell the interface stuff it already knows.  If there are no collisions, then
the language (which is the interface to the code generator in this case)
already knows what function you're referring to when you call, for example,

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to