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:
im
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
On 12/17/13, Leandro Motta Barros 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 rep
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 w
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);
On Wed, Dec 18, 2013 at 6:56 AM, Joseph Rushton Wakeling <
joseph.wakel...@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&
, 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:(
The following behavior seems odd to me. Could anyone explain why
it works as it does? (Does package.d have a page on dlang.org?)
--- main.d
module main;
void main()
{
test1();
test2();
}
void test1()
{
import pack;
// works
foo();
// works
Sorry, that's
--- pack/package.d
and
--- pack/sub.d
On Thursday, 16 January 2014 at 15:46:01 UTC, Lemonfiend wrote:
The following behavior seems odd to me. Could anyone explain
why it works as it does? (Does package.d have a page on
dlang.org?)
--- main.d
module main;
void main()
{
test1();
test2();
}
void test1
I think this is what you are looking for:
http://dlang.org/changelog.html#import_package
What an odd place to put it..
Too bad, it doesn't mention anything about calling the functions
like in my example, and why some do/don't work. I'd hoped for
more.
Hi!
I made similar questions here a month ago, but also couldn't get definitive
answers. I just sent a message about this to the main D forum. Let's see if
we have better luck there :-)
Cheers,
LMB
On Fri, Jan 17, 2014 at 5:39 PM, Lemonfiend wrote:
> I think this is what you are looking for
name
the book suggest somepack
and inside it add a module package.d , so you will end up
somepack/package.d
inside the file add
module somepack; //notice this named after the folder
//then public import std.stdio, somepack.one, somepack.two;
//etc
at first i though package.d is special name
I was perusing a PR for phobos where std/range.d was split into
submodules and std/range.d was moved to std/range/package.d
I was wondering why a package module had to be called "package.d"
instead of just being the package name. For example, instead of
moving std/range.d to
On Wednesday, 4 April 2018 at 04:54:50 UTC, Ali wrote:
at first i though package.d is special name, as in i must call
the file package.d or this trick or idiom to work
the trick was to have one module that public import all the
modules you import as group in other modules
so instead of
- the special package module
>
> this small section, suggest an idiom to create a package which
> can have any name
> the book suggest somepack
> and inside it add a module package.d , so you will end up
> somepack/package.d
> inside the file add
>
> > module somepa
On Monday, 10 November 2014 at 21:25:32 UTC, Jonathan Marler
wrote:
I was perusing a PR for phobos where std/range.d was split into
submodules and std/range.d was moved to std/range/package.d
I was wondering why a package module had to be called
"package.d" instead of just being t
On 11/10/14 4:33 PM, Dicebot wrote:
On Monday, 10 November 2014 at 21:25:32 UTC, Jonathan Marler wrote:
I was perusing a PR for phobos where std/range.d was split into
submodules and std/range.d was moved to std/range/package.d
I was wondering why a package module had to be called "pack
t practices in these sorts of situations.
I've got a simple project set up as follows:
.
├── dub.json
└── source/
├── app.d
└── my_package/
├── my_module.d
└── package.d
The contents of dub.json are pretty simple:
{
"name": "my_package_test"
Package.d is a real problem existing on our currently modules
design. First is that it means to take the directory name to use
as a module.
This is a problem for 3 reasons:
1. You won't be able to find your module by the file name. This
is incredibly common, for instance, in Visual S
![](https://i.imgur.com/829CzOS.png)
Source File **package.d** is a [package module][1] which contains
import statements to import other modules.
How would one import a **package.d** module when [**keyword
"package"**][2] is preventing that?
[1]: https://dlang.org/spec/m
Dne 8.11.2016 v 21:16 Bryce Kellogg via Digitalmars-d-learn napsal(a):
...
Finally, a one line package.d:
public import my_package.my_module;
Change it to:
module my_package;
public import my_package.my_module;
Btw, having class name same as module name is not best way, there could
be
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
...
I disagree completely with being against package.d.
Having used D for like a decade at this point, I've never
experienced any issues with it.
Most issues seems to be for newcomers and people who aren't
entirely fam
on it exists), random inconsistencies with the rest
of the language leading to link errors.
package.d is absolutely essential in some cases.
Which cases?
On Friday, 4 November 2022 at 14:11:55 UTC, bauss wrote:
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
...
I disagree completely with being against package.d.
Having used D for like a decade at this point, I've never
experienced any issues with it.
Most issues seems to b
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
...
What do we use instead?
I won't lie about the fact package.d forced me to workaround
elusive "bugs" in my usage(1) but what is the alternative if we
don't want to work around it?
(1)(ime : had cases of
On Friday, 4 November 2022 at 16:21:17 UTC, z wrote:
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
...
What do we use instead?
I won't lie about the fact package.d forced me to workaround
elusive "bugs" in my usage(1) but what is the alternative if we
don't
On Friday, 4 November 2022 at 16:56:59 UTC, Hipreme wrote:
[snip]
You can use any name instead. The only difference between an
ordinary source file and a package.d is the module name. For
instance, if you're inside the filesystem directory, you can
change the name to literally anythin
On Friday, 4 November 2022 at 19:10:33 UTC, jmh530 wrote:
If you don't plan to use private(package_name), then I don't
know what the point of it is.
This works fine without the package.d anyway.
On Friday, 4 November 2022 at 19:17:04 UTC, Adam D Ruppe wrote:
On Friday, 4 November 2022 at 19:10:33 UTC, jmh530 wrote:
If you don't plan to use private(package_name), then I don't
know what the point of it is.
This works fine without the package.d anyway.
Oh really, then what
n't know
> > > what the point of it is.
> >
> > This works fine without the package.d anyway.
>
> Oh really, then what's the point of package.d?
So that you can import abc.def separately from abc.def.ghi and
abc.def.jkl.
T
--
Meat: euphemism for dead animal. -- Flora
On Friday, 4 November 2022 at 19:34:58 UTC, jmh530 wrote:
Oh really, then what's the point of package.d?
It was originally added because Phobos had `std.algorithm` and
`std.datetime` and some people wanted to break them up into
pieces, but not break user code that still said `i
On Friday, 4 November 2022 at 19:40:09 UTC, H. S. Teoh wrote:
So that you can import abc.def separately from abc.def.ghi and
abc.def.jkl.
This isn't that hard; in the old days you'd have `pkg.foo` then
`import pkg.all` instead of `import pkg;`. The specific thing
that led to the
On 11/4/22 3:49 PM, Adam D Ruppe wrote:
On Friday, 4 November 2022 at 19:34:58 UTC, jmh530 wrote:
Oh really, then what's the point of package.d?
It was originally added because Phobos had `std.algorithm` and
`std.datetime` and some people wanted to break them up into pieces, but
not
On Friday, 4 November 2022 at 19:53:01 UTC, Adam D Ruppe wrote:
This isn't that hard; in the old days you'd have `pkg.foo` then
`import pkg.all` instead of `import pkg;`.
It was worse, you would do
import mylib.all;
and now it's just:
import mylib;
Also the "all" concept is bad, it s
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
Package.d is a real problem existing on our currently modules
design. First is that it means to take the directory name to
use as a module.
This is a problem for 3 reasons:
1. You won't be able to find your module by the file
On Saturday, 5 November 2022 at 01:34:04 UTC, ryuukk_ wrote:
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
Package.d is a real problem existing on our currently modules
design. First is that it means to take the directory name to
use as a module.
This is a problem for 3 reasons
On Saturday, 5 November 2022 at 10:18:33 UTC, Hipreme wrote:
On Saturday, 5 November 2022 at 01:34:04 UTC, ryuukk_ wrote:
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
Package.d is a real problem existing on our currently modules
design. First is that it means to take the
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
Package.d is a real problem existing on our currently modules
design. First is that it means to take the directory name to
use as a module.
If the example mentioned in this thread is not confusing,
package.d is a godsend. 😉
https
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
3. I'm currently having a bug on my API module that every
duplicated file name, even when located at different
directories(modules), are generating duplicate symbol. The
major problem is that this is currently undebuggable, as the
MSVC
Edit incorrect link to example:
[Extensive run.dlang.io
example](https://run.dlang.io/is/f3jURn)
Correct link:
https://run.dlang.io/is/Zbrn75
On 02.11.23 11:45, BoQsc wrote:
Edit incorrect link to example:
[Extensive run.dlang.io example](https://run.dlang.io/is/f3jURn)
Correct link:
https://run.dlang.io/is/Zbrn75
```
--- waffles/program.d
import waffles;
```
See https://dlang.org/spec/module.html#package-module
https://dlang.org/spec/module.html#package-module
Weirdly enough it does not work on Windows operating system.
![](https://i.imgur.com/x47fcNF.png)
```
program.d(1): Error: unable to read module `waffles`
program.d(1):Expected 'waffles.d' or 'waffles\package.d'
in
/Zbrn75
```d
--- waffles/program.d
import waffles;
void main()
{
import std;
writeln(num);
}
--- waffles/package.d
module waffles;
public import waffles.testing1;
public import waffles.testing2;
--- waffles/testing1.d
int num = 5;
--- waffles/testing2.d
int num2 = 9;
```
://run.dlang.io/is/f3jURn)
Correct link:
https://run.dlang.io/is/Zbrn75
```d
--- waffles/program.d
import waffles;
void main()
{
import std;
writeln(num);
}
--- waffles/package.d
module waffles;
public import waffles.testing1;
public import waffles.testing2;
--- waffles/testing1.d
--- waffles/program.d
import waffles;
void main()
{
import std;
writeln(num);
}
--- waffles/package.d
module waffles;
public import waffles.testing1;
public import waffles.testing2;
--- waffles/testing1.d
int num = 5;
--- waffles/testing2.d
int num2 = 9;
```
`num` and `num2` was never a
On Thursday, 2 November 2023 at 11:12:58 UTC, BoQsc wrote:
Weirdly enough it does not work on Windows operating system.
[...]
```
program.d(1): Error: unable to read module `waffles`
program.d(1):Expected 'waffles.d' or
'waffles\package.d' in one of the following i
`waffles.d` or `waffles/package.d`
**in your current working directory**.
So you have three options:
1. You can compile from the parent directory, most likely what
run.dlang.io does: `dmd -i -run waffles/program.d`
2. You can explicitly add all the files to the dmd invocation (I think
this is
Well the whole thread is about importing `package.d` while being
inside package to provide runnable working example which contains
debug information of the package.
Sidenote:
This is essentially useful when distributing over many
machines/platforms via `dub` package manager.
You would want
On Thursday, 2 November 2023 at 12:52:35 UTC, BoQsc wrote:
Therefore the need to import `package.d` is needed and I can't
see a solution, which means
tbh package.d should never be used. It is a poorly designed,
buggy misfeature of the language with plenty of better working
alternative
On 02.11.23 13:52, BoQsc wrote:
Well the whole thread is about importing `package.d` while being inside
package to provide runnable working example which contains debug
information of the package.
Sorry, but I have never seen a package that includes examples within the
package directory
On 02.11.23 14:15, Arafel wrote:
You simply can't expect to do `import waffle.foo` from within `waffle/`
itself (unless you have another `waffle` folder in it, which is often
the case).
Sorry, this is wrong. It should read:
You simply can't expect to do `import waffle.foo` **when invoking
On Thursday, 2 November 2023 at 12:52:35 UTC, BoQsc wrote:
Therefore the need to import `package.d` is needed and I can't
see a solution, which means
that D Language might have to introduce a way to import
`package.d` from inside the package, if there is a need to
further improve exper
On Thursday, November 2, 2023 7:04:37 AM MDT Adam D Ruppe via Digitalmars-d-
learn wrote:
> On Thursday, 2 November 2023 at 12:52:35 UTC, BoQsc wrote:
> > Therefore the need to import `package.d` is needed and I can't
> > see a solution, which means
>
> tbh package.d sho
ackage leads to inconsistent reflection results
im sure the list went on if i spent a few more minutes looking
for my archives)
package.d is indeed completely unnecessary for creating a
module that publicly imports other modules in order to be able
to import a single module and get several modu
ges
hit random problems
all-at-once vs separate compilation of
package leads to inconsistent reflection results
im sure the list went on if i spent a few more minutes looking
for my archives)
package.d is indeed completely unnecessary for creating a
module that publicly imports other modules
w_bug.cgi?id=20563 error messages hit random
> > problems
> > all-at-once vs separate compilation of package
> > leads to inconsistent reflection results
> >
> > im sure the list went on if i spent a few more minutes looking for my
> > archives)
> >
>
*/
// pkg/mymodule/pub_submod.d
module mymodule.pub_submod;
... // code here
// pkg/mymodule/priv_submod.d
module mymodule.priv_submod;
... // code here
// pkg/mymodule/package.d
module mymodule;
public import priv_submod
implementation actually goes. (Or you could call it whatever you
want.) This avoids the whole package.d thing while still letting
you and your user arrange modules how you like.
You might also have a thing like `foo.bar_implementation` which
is not intended for public use.
>
> > // pkg/mymodule/priv_submod.d
> > module mymodule.priv_submod;
> > ... // code here
> >
> > // pkg/mymodule/package.d
> > module mymodule;
> > public import priv_submod;
> >
> > // main.d
> >
On Friday, 3 November 2023 at 18:04:58 UTC, Jonathan M Davis
wrote:
- Jonathan M Davis
Thanks a lot for detailed explanation!
I've only understood that imports should go in package.d. I'm
seeing more and more packages on code.dlang.org using it for the
packages primary code. Is this alright? As far as I can tell it's
just bad form. It would be nice to have one of the maintainers
higher up the food c
On Wednesday, January 03, 2018 06:10:10 Soulsbane via Digitalmars-d-learn
wrote:
> I've only understood that imports should go in package.d. I'm
> seeing more and more packages on code.dlang.org using it for the
> packages primary code. Is this alright? As far as I can tell i
On Wednesday, 3 January 2018 at 07:43:52 UTC, Jonathan M Davis
wrote:
On Wednesday, January 03, 2018 06:10:10 Soulsbane via
Digitalmars-d-learn wrote:
[...]
The entire reason that the package.d feature was added was so
that it would be possible to split a module into a package
without
On Wed, Jan 03, 2018 at 12:43:52AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Wednesday, January 03, 2018 06:10:10 Soulsbane via Digitalmars-d-learn
> wrote:
> > I've only understood that imports should go in package.d. I'm seeing
> > more and mor
65 matches
Mail list logo