package.d behavior

[Leandro Motta Barros]

Hi,

Do anyone has any feedback about his issue? I (and at least one more user)
believe that the "package.d" feature behaves strangely (please, see the
examples in my original post).

Thanks a lot,

LMB

PS: I am not a big fan of "bump" posts, but I believe this message may have
been ignored given some forum issues last week -- when it appeared, it was
already buried under several more recent messages.


On Sat, Jan 18, 2014 at 10:32 AM, Leandro Motta Barros <lmb at stackedboxes.org
> wrote:

> Hello!
>
> About a month ago I asked in D.learn about the expected behavior of the
> new package.d feature [1]. I got a cuple of responses, but not really
> answers. Today I noticed a second post [2] with similar but still
> unanswered questions. So it seemed like a good idea to bring the discussion
> to the main forum.
>
> Basically, I seems that the root of the issues we are facing is the way
> fully-qualified names work when using package.d (I have added some examples
> below showing what I mean).
>
> We also felt that the feature is under-documented (DIP37 and the changelog
> seem to be the only places where the feature is discussed, and some
> important details are missing.) I was actually about to fill bug a report
> about the behavior, but I ended up not doing so because I couldn't find out
> what the expected behavior is.
>
> So, any feedback and clarifications are welcome!
>
> Thanks for the attention, and keep up the great work :-)
>
> LMB
>
> [1]
> http://forum.dlang.org/thread/CANY+vSMzLJ5ehKGW8cE1KkoMOm7x3roKmVgMjyCqZrwD9aLO9w@mail.gmail.com
> [2] http://forum.dlang.org/thread/eeaslvjwenkygwszqznc@forum.dlang.org
>
>
> -----------------------
>
> EXAMPLE 1: Trying to simply replace the old "all.d" idiom with package.d
> doesn't work out-of-the-box:
>
> 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
>
> [Using mylib.Foo instead of mylib.util.Foo works -- which makes sense when
> thnking about the use case of using package.d to split a large package into
> smaller ones. ]
>
>
> ---------------------
>
> EXAMPLE 2: Inconsistency with fully-qualified names
>
> // 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
>
> [This looks very much like a bug for me. The name given by classinfo.nameshould be usable to instantiate a class, shouldn't it? ]
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140123/f89f4cda/attachment.html>