http://d.puremagic.com/issues/show_bug.cgi?id=3503



--- Comment #10 from Bill Baxter <wbaxter@gmail.com> 2009-11-14 11:06:28 PST ---
(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.

With this proposal you could keep using them the same way just by adding ":*" at the end of each module name.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3503



--- Comment #11 from Leandro Lucarella <llucax@gmail.com> 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
system.

> 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3503


Nick Sabalausky <cbkbbejeap@mailinator.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbkbbejeap@mailinator.com


--- Comment #12 from Nick Sabalausky <cbkbbejeap@mailinator.com> 2009-11-15 23:46:52 PST ---
Another problem with this idea is that the default behavior would kill array property syntax:

-------
module foo;
void useArray(int[] a) {...}
-------
module main;
import foo;
void main()
{
    int a = [1,2,3];
    a.useArray(); // Breaks under this proposal
    a.foo.useArray(); // Invalid regardless
}
-------

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3503



--- Comment #13 from Leandro Lucarella <llucax@gmail.com> 2009-11-16 12:46:55 PST ---
(In reply to comment #12)
> Another problem with this idea is that the default behavior would kill array property syntax:
> 
> -------
> module foo;
> void useArray(int[] a) {...}
> -------
> module main;
> import foo;
> void main()
> {
>     int a = [1,2,3];
>     a.useArray(); // Breaks under this proposal
>     a.foo.useArray(); // Invalid regardless
> }
> -------

Doesn't kills it, it only make it more explicit:

module main;
import foo: useArray;
void main()
{
    int a = [1,2,3];
    a.useArray(); // Breaks under this proposal
}

Again, bug 3504 is a good companion for this proposal for some special cases
(like std.string).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3503


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dawg@dawgfoto.de
         Resolution|                            |WONTFIX


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------