--- Comment #11 from Leandro Lucarella <> 2009-11-14 12:34:31 
PST ---
(In reply to comment #9)
> (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.

I think you're mistaking syntactic noise with semantic information. Writing the
module name *does* have semantic information, even when you can find it too
verbose. It's not the same to use, for example, path.join() than string.join(),
the module carries semantic information. Of course you can name the functions
path_join() and string_join(), but that kind of defeat the point of a module

> 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.

I don't think a language should depend on a good IDE, if you take that too far
you end up with Java. I really think the "the IDE should do that" is the worse
argument ever. I don't even use a IDE (not because there is no good IDE for D,
I just don't use IDEs for any languages). But this is besides the point,
because this discussion is just about personal preferences.

> 2.  What do you do more, write/read code or track dependencies?

read the code and 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,
> sort().

But I don't know where that sort came from. I'm missing important information
(when reading a program). You either have very long and descriptive function
names, or you use the module system properly. I agree that when you use a
symbol a lot is desirable to have it imported in the main namespace, but in
that case you can always use selective imports. With selective imports you get
the less typing for things you use a lot *plus* you can know where every symbol
came from.

And again, we are only talking about changing the *default*, you can always use
import * if you want to.

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

Reply via email to