Le 30/03/2012 23:35, Jonathan M Davis a écrit :
On Friday, March 30, 2012 14:33:58 Andrei Alexandrescu wrote:
On 3/30/12 1:39 PM, Jonathan M Davis wrote:
However, I'm very nervous about the second part. e.g. std.sort instead of
std.algorithm.sort seems like a bad idea to me. It increases the odds of
name conflicts for little benefit.
Example?
std.sort works because there's only one sort. If there are two, you get a
conflict (e.g. if you had std.path.sort which sorted paths in some path-specific
manner). If std.path.sort existed now, then std.sort wouldn't work, and you'd
be forced to specify std.algorithm.sort or std.path.sort, and that's fine. It
would be similar to having to specify std.algorithm.indexOf when you've
imported both std.string and std.algorithm. But the problem is when
std.path.sort is added _later_.
I mentionned that as being a ptotential issue, so this is a +1 .
But personally, I like the idea of making it so that publicly imported symbols
can be accessed as if they were in the module that publicly imported them
(with package.d being treated as if it had the same name as the package that
it's in). That's essentially how it already works except when specifying the
full import path for a symbol. And that way, you can specify in
std.algorithm.package.d exactly what you want to be imported when
std.algorithm is imported (including using : to restrict it to specific symbols
in a module), and only those symbols will be treated as if they were part of
std.algorithm - both for importing purposes and when specifying the import
path when using a symbol. The library maintainer then has control over which
symbols get used with which import paths.
- Jonathan M Davis
I did propose that in another thread, so this is a +1 too.
