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
<[email protected]
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+vsmzlj5ehkgw8ce1kkomom7x3rokmvgmjycqzrwd9al...@mail.gmail.com
[2]
http://forum.dlang.org/thread/[email protected]
-----------------------
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? ]
