digitalmars.D.bugs - [Issue 3819] New: [module system] Tiding up the imports
- d-bugmail puremagic.com (34/34) Feb 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (23/23) Feb 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (22/24) Feb 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (20/20) Feb 23 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (10/10) Feb 23 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (12/12) Feb 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (18/23) Feb 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (19/23) Feb 24 2010 In Python that's doesn't happen, people usually import just the module n...
- d-bugmail puremagic.com (19/47) Feb 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (20/49) Feb 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (12/12) Feb 14 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3819
- d-bugmail puremagic.com (27/27) Feb 14 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3819
http://d.puremagic.com/issues/show_bug.cgi?id=3819 Summary: [module system] Tiding up the imports Product: D Version: 2.040 Platform: All OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc import std.stdio; void main() { std.stdio.writefn(1); writefln(2); // (A) } This program has to raise a compilation error at the line (A), because this line: import std.stdio; Has to import only the 'std.stdio' name in the current namespace. To import (discouraged practice) all names from a module a specific syntax may be invented, like: import std.stdio.*; void main() { writefln(1); std.stdio.writefn(2); // (B) } That imports all the names but not the module name itself, so the line (B) has to raise an error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 BCS <shro8822 vandals.uidaho.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shro8822 vandals.uidaho.edu --- I think this would be bad idea and vote that it be closed. --- Rational: There already exist way to use import where the fully qualified name is still needed (IIRC static imports) so that covers the one case. There already exists a way to use import to a selected subset of symbols from a module. The most common case is the "import everything" case. With the modification, in the normal case, it becomes impossible to, in the same module, use fully qualified names and to not use them. --- I don't see any advantage to it (either in functionality, consistency, conciseness or anything else I care about). Unless I'm missing something, I think the proposal would detract from the language. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 Answer to BCS: I think this is the most important bug I've filed among the first 15 ones. The standard way to import must be the one that's tidy, that is not importing all names randomly into the namespace. If you have functions, they can use global values coming from a module, and you don't know from what module they come from. If you really really want to import all the names in a namespece I've shown you a very easy syntax to do that: import std.stdio.*; It's just 2 chars longer than the current syntax you use: import std.stdio; So you don't wear your fingers out if you want to use that all times.There already exist way to use import where the fully qualified name is stillneeded (IIRC static imports) so that covers the one case.< That's the wrong default.With the modification, in the normal case, it becomes impossible to, in thesame module, use fully qualified names and to not use them.< And this (if I understand you correctly) is good. Because newbies (and all people coming from Python) people will understand this tidier behaviour faster. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 I can show you some funny examples, this is a reduced bug that comes from real code (not written by me) (this codes currently compiles, but it's not good): import std.c.stdio; enum int BUFFSIZE = 2048; long[BUFSIZ] foo; void main() {} The basics of systems theory tells that to improve the reliability of an engineering system you have to put discipline in how its subsystems interact to each other. Reducing unwanted interactions among subsytems improves reliability a lot. D module system is not tidy, there can be unwanted interactions that lead to bugs. The module system of Python doesn't share this vulnerability, it's designed in a logically tidy way. Overload sets introduced in D can't fix the situation, they are just a patch on a situation on a module system design that is logically unsound. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 23 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 --- I don't think that shows as a problem in the import system. While your proposal would fix the problem in that case, there are plenty of other versions of the same bug that wouldn't get fixed. For this case, it would be like expecting Toyota drivers to fix there sticky gas pedals by driving around with flat tires. Yes it would fix the problem but it's not a good idea. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 23 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 Maybe I was not clear enough: in a complex system if you want to avoid many bugs you have to reduce the interface area between subsystems, to reduce the number of unwanted interactions between them. When possible you want to know the interactions among them, to allow only the useful ones. So it's good to have a way to list in explicit way what interactions they share. Importing all names randomly from a module as default behaviour leads to a mess. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 ---Maybe I was not clear enough:No you were clear enough. I just don't think that your proposal is the correct solution (and I'm not sure that the problem even needs to be solved). Clearly, there are better and worse solutions to the problem (if dmd aborts for all code it would reject all bugs) and I think that your solution is slightly worse than doing nothing. I think that because it will get in the way of the programmer and I expect that ,in practice, it will not solve the problem because people will just use "import foo.*;" by default.So it's good to have a way to list in explicit way what interactions they share.We have that right now.Importing all names randomly from a module as default behaviour leads to a mess.If importing all names from a module imports *random* names, than the problem is not the import system, but what is in the module. I'll maintain that in a well designed library, if you need one thing from a module, you will need many/most of the things in it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819I think that because it will get in the way of the programmer and I expect that ,in practice, it will not solve the problem because people will just use "import foo.*;" by default.<In Python that's doesn't happen, people usually import just the module name, or some names from the module. The import all is discouraged. And when people what to use the unqualified import syntax, adding two chars ".*" is not going to cost them much.We have that right now.<We don't have it, there's a whole page about mitigating this problem: http://www.digitalmars.com/d/2.0/hijack.html And Overload Sets have being introduced as a patch on this problem.If importing all names from a module imports *random* names, than the problemis not the import system, but what is in the module.< By "random names" I didn't mean they are truly random, I mean that you don't know what you are importing.I'll maintain that in a well designed library, if you need one thing from a module, you will need many/most of the things in it.<In Phobos there are modules with 20-30 names of functions and other stuff. User defined modules can have even more. D is not Java, you are supposed to put related classes inside a single module. So about 100% of the times I don't use all things that are present in those modules. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 David Simcha <dsimcha yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsimcha yahoo.com I think the point everyone is missing here is that, unlike most other languages, D doesn't allow hijacking, **period**. The best practices that apply to languages that allow hijacking simply don't apply to D. While in other languages it may lead to subtle bugs and be considered sloppy programming, in D I see nothing wrong with just saying "ah fsck it I want to save a little typing" and import 5,000 names into the current namespace, because it's **not going to lead to any subtle bugs**. It will either compile and work fine or it won't compile and will tell you where the ambiguity is. This is why I really, really, really, **really** wish there was a std.all.-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------I think that because it will get in the way of the programmer and I expect that ,in practice, it will not solve the problem because people will just use "import foo.*;" by default.<In Python that's doesn't happen, people usually import just the module name, or some names from the module. The import all is discouraged. And when people what to use the unqualified import syntax, adding two chars ".*" is not going to cost them much.We have that right now.<We don't have it, there's a whole page about mitigating this problem: http://www.digitalmars.com/d/2.0/hijack.html And Overload Sets have being introduced as a patch on this problem.If importing all names from a module imports *random* names, than the problemis not the import system, but what is in the module.< By "random names" I didn't mean they are truly random, I mean that you don't know what you are importing.I'll maintain that in a well designed library, if you need one thing from a module, you will need many/most of the things in it.<In Phobos there are modules with 20-30 names of functions and other stuff. User defined modules can have even more. D is not Java, you are supposed to put related classes inside a single module. So about 100% of the times I don't use all things that are present in those modules.
Feb 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 ---I don't have any solid evidence, but I strongly suspect that the above would not happen for D. It seems to me that the cost benefit balance falls in favor of just importing everything. I suspect that it's similar to how in dynamic languages there is a much stronger argument for TDD because, IIRC, python is a dynamic language and D is not.I think that because it will get in the way of the programmer and I expect that ,in practice, it will not solve the problem because people will just use "import foo.*;" by default.In Python that's doesn't happen, people usually import just the module name, > or some names from the module. The import all is discouraged.And when people what to use the unqualified import syntax, adding two chars ".*" is not going to cost them much.Not my point. In fact the ease of adding it supports my point.Let me be more precise: we have selective imports right now.We have that right now.We don't have it, there's a whole page about mitigating this problem: http://www.digitalmars.com/d/2.0/hijack.html And Overload Sets have being introduced as a patch on this problem.I still maintain my point, if you needs something out of a module than importing every name in a module shouldn't import random names (using your definition) unless the module is poorly designed.If importing all names from a module imports *random* names, than the problem is not the import system, but what is in the module.By "random names" I didn't mean they are truly random, I mean that you don't know what you are importing.20-30 names? Is it that low? I thought you were talking about hundreds of names. Now I'm not even sure why you are bothering.I'll maintain that in a well designed library, if you need one thing from a module, you will need many/most of the things in it.In Phobos there are modules with 20-30 names of functions and other stuff. User defined modules can have even more.D is not Java, you are supposed to put related classes inside a single module. So about 100% of the times I don't use all things that are present in those modules.Most of the time using Phobos, I want to have most of or none of a module available (even if I don't use some of it). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3819 dawg dawgfoto.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dawg dawgfoto.de Resolution| |WONTFIX Too late, too much code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 14 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3819 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 12:16:57 PST --- I agree. D has excellent support for anti-hijacking, which I feel serves the purpose well. As for this case: import std.c.stdio; enum int BUFFSIZE = 2048; long[BUFSIZ] foo; void main() {} That's a general problem with typos, not specifically with imports. I don't see any hope for any computer language to fix this. All computer languages rely on different names being completely distinct, even if they differ by only one character. There's no solution for it. You could perhaps write a lint program that looked for names in scope that differed by only one character in the middle of the identifier and issued warnings, but I can't see that as being part of the language. In any case, 1. mucking with how imports work is the wrong solution to typos 2. this would break every D program in existence Wontfix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 14 2012