David Simcha <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #8 from David Simcha <> 2010-02-24 14:47:47 PST ---
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.

(In reply to comment #7)
> >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:
> And Overload Sets have being introduced as a patch on this problem.
> >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.
> >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:
------- You are receiving this mail because: -------

Reply via email to