DIP16: Transparently substitute module with package

deadalnix deadalnix at gmail.com
Sat Mar 31 08:35:27 PDT 2012


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.


More information about the Digitalmars-d mailing list