On Thu, 05 Apr 2012 11:23:12 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 4/5/12 7:43 AM, Steven Schveighoffer wrote:
I currently think DIP16 is invalid/worksforme (public imports allows
splitting a module into a package). All that is left is how we could
specifically import a package with one import statement.
Not entirely (I was aware of the way public import works). An issue does
exist - there are "too many names", i.e. the alias pulled in the
importing module and also the name being imported. This makes for odd
synonyms such as std.algorithm_package.sort.sort being the same as
std.algorithm.sort.
Right, but if one only ever imports std.algorithm, who cares what the
submodule FQNs are?
AIUI, DIP16 also doesn't really reduce the number of names either.
The other issue is that obviously algorithm_package and algorithm must
have distinct names, which makes the scheme a bit awkward at least until
we define a compelling convention. I guess we can live with all that.
Agreed. I think Don mentioned std.math already does something, we may
want to look at that model.
A couple issues that still need consideration:
1. If std.algorithm the module becomes std.algorithm the package, what
happens with ddoc? We probably *do* need a compiler solution to this.
2. deadalnix pointed out that if we come up with a scheme where the
package module and its submodules are in the same directory, the package
accessibility qualifier can be used (hey look, a use for the package
keyword!).
-Steve
