== Quote from Michiel Helvensteijn ([email protected])'s article > Michiel Helvensteijn wrote: > > Your std.string.find() may carry the `algorithm' tag and the `string' tag. > > So perhaps if both (or either?) of those tags are imported into a project, > > the function would become available. > Hm.. I suppose a project could import any Boolean combination of tags: > import algorithm & string; > import algorithm | string; > import algorithm & !string; > And if modules were gone, I suppose you'd want to tag all your > standard-library functions with `std' as well. > A bit too radical a change, I suppose. But I believe I will think about this > some more. What do you think?
This seems like overkill. Module/package/import/whatever management should not require a Ph.D. in Boolean logic. It should be dead simple (i.e. like the current system is, esp. after 314 gets fixed) and allow people to get on with solving real problems. Yes, namespace pollution is annoying, but so is a ridiculously fine-grained import system. After all, the whole point of a module system is to avoid namespace pollution. Otherwise, it would make sense to just import every darn module in every import path implicitly. Sometimes, when people get ridiculously crazy with hierarchical import structure and stuff, I feel like just having a more polluted namespace is the lesser of two evils, especially in D, where naming collision resolution is well-defined and sane.
