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 Cod
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 with ho
On Friday, 4 November 2022 at 14:11:55 UTC, bauss wrote:
Having used D for like a decade at this point, I've never
experienced any issues with it.
Lucky you, lots of other people have. Broken phobos updates,
impossible to transition to it without code breakages (which is
the only reason it ex
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 be for
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 requiring compil
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 work around i
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 and im
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's the point
On Fri, Nov 04, 2022 at 07:34:58PM +, jmh530 via Digitalmars-d-learn wrote:
> 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 poin
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
std.algo
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 thi
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 us
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 name. Th
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 directory
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
19 matches
Mail list logo
