DIP16: Transparently substitute module with package

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Mar 30 14:49:37 PDT 2012


On Fri, Mar 30, 2012 at 05:35:25PM -0400, Jonathan M Davis wrote:
[...]
> 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.
[...]

+1.

I also have my doubts about the wisdom of std.sort implicitly binding to
std.algorithm.sort. It's nice syntactic sugar in the short term, but as
Jonathan points out, it can cause headaches in the long term. I say we
should hold off on that part of the proposal.


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.


More information about the Digitalmars-d mailing list