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@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
>
>

On 12/17/13, Leandro Motta Barros <lmb@stackedboxes.org> wrote:
> Is there any documentation describing the expected to behavior in regard to the fully-qualified names of the publicly imported symbols in package.d?

It might have been an oversight, but we'll have to wait for (I think Kenji) to reply since he implemented packages.

On 17/12/13 01:51, Leandro Motta Barros wrote:
> I have some code using the old "all.d" idiom, which I am changing to use the new
> "package.d" feature.

Related question -- it seems like rdmd doesn't like package-based code, and can't resolve dependencies as it can with regular modules.  Is there any kind of timeframe/roadmap for fixing this?

Here's another rather interesting case:

// mylib/util.d
module mylib.util;
class Foo { }

// mylib/package.d
module mylib;
public import mylib.util;

// main.d
import std.stdio;
import mylib;

void main()
{
   auto f = new mylib.Foo;
   writefln("%s", f.classinfo.name);
}

 This prints 'mylib.util.Foo'. So far so good, that's the name I originally
expected.

Then I try to instantiate a 'Foo' using this very fully-qualified name the compiler told me:

   auto f = new mylib.util.Foo;

And DMD doesn't like it anymore:

main.d(6): Error: undefined identifier 'util'
main.d(6): Error: mylib.util.Foo is used as a type

Fishy, isn't it? Maybe I should report this as a bug?

Cheers,

LMB



On Wed, Dec 18, 2013 at 6:09 AM, Andrej Mitrovic <andrej.mitrovich@gmail.com
> wrote:

> On 12/17/13, Leandro Motta Barros <lmb@stackedboxes.org> wrote:
> > Is there any documentation describing the expected to behavior in regard
> to
> > the fully-qualified names of the publicly imported symbols in package.d?
>
> It might have been an oversight, but we'll have to wait for (I think Kenji) to reply since he implemented packages.
>

On Wed, Dec 18, 2013 at 6:56 AM, Joseph Rushton Wakeling < joseph.wakeling@webdrake.net> wrote:

> On 17/12/13 01:51, Leandro Motta Barros wrote:
>
>> I have some code using the old "all.d" idiom, which I am changing to use
>> the new
>> "package.d" feature.
>>
>
> Related question -- it seems like rdmd doesn't like package-based code, and can't resolve dependencies as it can with regular modules.  Is there any kind of timeframe/roadmap for fixing this?
>

With these simple examples I sent, rdmd seem to resolve dependecies correctly. For example, with this last example I sent (which prints the class name):

$ rdmd main.d
mylib.util.Foo

$ dmd main.d
main.o: In function `_Dmain':
main.d:(.text._Dmain+0xb): undefined reference to
`_D5mylib4util3Foo7__ClassZ'
collect2: error: ld returned 1 exit status
--- errorlevel 1

$ dmd main.d mylib/util.d
$ ./main
mylib.util.Foo

In this case, at least, rdmd correctly resolved, compiled and linked mylib/util.d, which was imported through a package.

LMB

On 18/12/13 10:41, Leandro Motta Barros wrote:
> With these simple examples I sent, rdmd seem to resolve dependecies correctly.
> For example, with this last example I sent (which prints the class name):
>
> $ rdmd main.d
> mylib.util.Foo

If I create an example analogous to yours, it seems OK.  However, I was dealing with a case where the package is at the 2nd level of the subdirectory hierarchy:

    std/random2/package.d
    std/random2/generator.d
    std/random2/distribution.d

and so on.  That might have something to do with it.

> $ dmd main.d
> main.o: In function `_Dmain':
> main.d:(.text._Dmain+0xb): undefined reference to `_D5mylib4util3Foo7__ClassZ'
> collect2: error: ld returned 1 exit status
> --- errorlevel 1

Well, quite.  dmd doesn't resolve dependencies, it expects you to pass it all the necessary source or object files ...

> $ dmd main.d mylib/util.d
> $ ./main
> mylib.util.Foo

... like this.

> In this case, at least, rdmd correctly resolved, compiled and linked
> mylib/util.d, which was imported through a package.

I think that there must be a problem with packages that are in the 2nd rather than 1st level of the subdirectory hierarchy.