std.string and std.algorithm: what to do?

[Leandro Lucarella]

dsimcha, el 14 de mayo a las 19:50 me escribiste:
> == Quote from Michiel Helvensteijn (m.helvensteijn.remove at gmail.com)'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.

I think the module system of D is pretty good, but there are a few things
that can be improved (besides bugs =).

As suggested in the path, I think the default should be static imports
(like it's safest to default globals to be threadlocal, it's safer, or
clearer for a code reviewer to use static imports by default).

If you want to import all, something like import module: *; ca be added
(like __gshared ;).

There are a few other shortcomings that I don't remember now that can be
fixed (I think modules can't have the same name as the package they are
in or something).

It would be nice to be able to put symbols in a package (a la Python).
This can be easily done by allowing a .d file and a directory with the
same name. For example:

x/y.d
module x.y;
void f() {}
void g() {}

x.d
module x;
import x.y: g;

z.d
import x;

x.f(); // error
x.g(); // ok

This allows to have some kind of "private modules", leaving the public
interface in the package itself. Without this you have to use a "nested
main module":

z.d
import x.y;
x.y.g(); // why the user how to know about the details of package x?


This last one maybe is more a matter of taste than a real issue...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------