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

On Thursday, 23 January 2014 at 11:43:07 UTC, Leandro Motta Barros wrote:
> 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,

You should probably file a bug. I think this change should be valid (it sounds like it wouldn't work, but didn't test)

------
    static import mypackage.util;

    alias sym = mypackage.util.func;
------

Changed to:

------
    import mypackage;

    alias sym = mypackage.util.func;
------

That is to say, changing from a specific module import to a "package" import should still allow fully qualified names so that code would not be required to change.

That at least one more user here :)

package.d really deserves more than just a changelog entry. Like a proper mention in the docs, with a description of its expected behaviour.
Then users would at least be able to determine whether something was a bug or working as intended.

On Thursday, 23 January 2014 at 11:43:07 UTC, Leandro Motta Barros wrote:
> 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@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? ]

On Fri, Jan 24, 2014 at 12:45 AM, Jesse Phillips < Jesse.K.Phillips+D@gmail.com> wrote:

> [...]
> You should probably file a bug. I think this change should be valid (it
> sounds like it wouldn't work, but didn't test)
>

There it is: https://d.puremagic.com/issues/show_bug.cgi?id=12014

LMB

> package.d really deserves more than just a changelog entry. Like a proper mention in the docs, with a description of its expected behaviour.
> Then users would at least be able to determine whether something was a bug or working as intended.

Just to remind you - dlang.org is in Github, and D people like pull requests...