On Friday, 3 November 2023 at 18:04:58 UTC, Jonathan M Davis
wrote:
- Jonathan M Davis
Thanks a lot for detailed explanation!
>
> > // pkg/mymodule/priv_submod.d
> > module mymodule.priv_submod;
> > ... // code here
> >
> > // pkg/mymodule/package.d
> > module mymodule;
> > public import priv_submod;
> >
> > // main.d
> >
the
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/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
563 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)
> >
> >
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 in order
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 modules.
Yeah
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
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 experience
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 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 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
alternatives
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
`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
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 import paths:
import
--- 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
://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
/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
int num = 5;
--- waffles/testing2.d
int num2 = 9;
```
https://dlang.org/spec/module.html#package-module
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
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
Edit incorrect link to example:
[Extensive run.dlang.io
example](https://run.dlang.io/is/f3jURn)
Correct link:
https://run.dlang.io/is/Zbrn75
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
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
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 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
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 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 name
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
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 break
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 package.d
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 `import
'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: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's the point
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 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 anything
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 want to w
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 package.d
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
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 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 familiar
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 Studio
- 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
>
> > mo
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
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
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 more packages
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 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 it's
> j
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 chain comment
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
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",
"description&q
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 std/range
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 the package
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 package.d
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 le...@fie.nd wrote:
I think this is what you are
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.
Sorry, that's
--- pack/package.d
and
--- pack/sub.d
On 12/17/13, Leandro Motta Barros l...@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
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
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
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 feature.
Related question -- it seems like rdmd doesn't
, 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
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
63 matches
Mail list logo
