package.d
Leandro Motta Barros
lmb at stackedboxes.org
Tue Dec 17 14:09:56 PST 2013
Hello again,
Reading DIP 37 ( http://wiki.dlang.org/DIP37 ) shed some light on the
issue, I think.
The motivation for package.d was to allow the split of a large module into
a package. From this perspective, the difference between package.d and
all.d regarding the fully-qualified names seems to make sense. But then,
the same DIP 37 says that "[using package.d] is identical to what some
projects have been doing with *all.d*, where they have a
*foo/bar/all.d*which publicly imports all of the
*bar* package, except that this provides additional syntactic sugar for it."
Is there any documentation describing the expected to behavior in regard to
the fully-qualified names of the publicly imported symbols in package.d? (
http://dlang.org/module.html doesn't mention package imports;
http://dlang.org/changelog.html#import_package doesn't mention
fully-qualified names).
Thank again,
LMB
On Mon, Dec 16, 2013 at 10:51 PM, Leandro Motta Barros <lmb at stackedboxes.org
> wrote:
> Hello,
>
> I have some code using the old "all.d" idiom, which I am changing to use
> the new "package.d" feature.
>
> Originally, I had something like this:
>
> // mylib/util.d:
> module mylib.util;
> class Foo { }
>
> // mylib/all.d:
> module mylib.all;
> public import mylib.util;
>
> // main.d:
> import mylib.all;
> void main()
> {
> auto f = new mylib.util.Foo;
> }
>
> And this used to work. Now, I added a new file:
>
> // package.d
> module mylib;
> public import mylib.util;
>
> And changed the 'import' in the main one:
>
> // main.d
> import mylib;
>
> void main()
> {
> auto f = new mylib.util.Foo;
> }
>
> Now, the compiler complains:
>
> main.d(5): Error: undefined identifier 'util'
> main.d(5): Error: mylib.util.Foo is used as a type
>
> Isn't this 'package.d' feature supposed to work just as the old 'all.d'
> and '_,d' we used before?
>
> (I see that I can use 'mylib.Foo' instead of 'mylib.util.Foo', but
> http://dlang.org/module.html is clear saying that "[a]ll symbols from a
> publicly imported module are also aliased in the importing module. This
> means that if module D imports module C, and module C *publicly* imports
> module B which has the symbol *bar*, in module D you can access the
> symbol via bar, B.bar, and C.bar.")
>
> I am using DMD 2.064 here.
>
> Thanks,
>
> LMB
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20131217/892989b3/attachment.html>
More information about the Digitalmars-d-learn
mailing list