www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Hipreme's #4 Tip of the day - Don't use package.d

reply Hipreme <msnmancini hotmail.com> writes:
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 Code, when 
you hit CTRL+P and type the file name, nope, you will need to 
write path/to/folder/package.d, beyond that, when you search 
package.d there will be so many files with the same name.

2. As being an exception to how the module system works, this has 
already caused me a few headaches (inexplicable bugs), that 
happens with symbols aliasing, when the time it happened, I had 
no idea on what it could be and I don't even remember how I 
solved, instead, I only knew it was related to package.d.

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 
Linker does not show the full directory of the libraries/object 
files that caused this clash, not even the symbol!

The duplicate symbol currently only happens in MSVC Linker, which 
makes me think if the bug is in the D language or the linker 
itself, as on LLD this does not happen.
So, my current advice is always try making your file names 
unique, this will bring a much better debuggability in your 
project.
Nov 04 2022
next sibling parent reply bauss <jacobbauss gmail.com> writes:
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 how D modules and packages work.

package.d is absolutely essential in some cases.
Nov 04 2022
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
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 exists), random inconsistencies with the rest 
of the language leading to link errors.


 package.d is absolutely essential in some cases.


Which cases?
Nov 04 2022
prev sibling parent Hipreme <msnmancini hotmail.com> writes:
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 newcomers and people who aren't 
 entirely familiar with how D modules and packages work.

 package.d is absolutely essential in some cases.


Literally my linker error disappeared after I changed it to 
another name.
And I can't see how essential package.d is, there's no D 
difference in the code written.

As it being the exception inside our compiler, it is an entire 
pool for bugs to get wild out there.
Nov 04 2022
prev sibling next sibling parent reply z <z z.com> writes:
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 compiler specific 
pragmas for LDC, and dub can't find the package's `source` files 
at all if it's a multi file subpackage intended to be imported 
only, i never got it working with `package.d`, only a single 
source file setup `*packagename*.d` would work...)
Nov 04 2022
parent reply Hipreme <msnmancini hotmail.com> writes:
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 it?

 (1)(ime : had cases of package.d requiring compiler specific 
 pragmas for LDC, and dub can't find the package's `source` 
 files at all if it's a multi file subpackage intended to be 
 imported only, i never got it working with `package.d`, only a 
 single source file setup `*packagename*.d` would work...)



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 import instead. To make 
my engine's names unique I have been using a convention for the 
package.d names as an abbreviation of the directory name plus 
`definitions` or something like that.
Nov 04 2022
parent reply jmh530 <john.michael.hall gmail.com> writes:
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 import instead. To 
 make my engine's names unique I have been using a convention 
 for the package.d names as an abbreviation of the directory 
 name plus `definitions` or something like that.


If you don't plan to use private(package_name), then I don't know 
what the point of it is.
Nov 04 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
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.
Nov 04 2022
parent reply jmh530 <john.michael.hall gmail.com> writes:
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 of package.d?
Nov 04 2022
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Nov 04, 2022 at 07:34:58PM +0000, 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 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
Nov 04 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
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 thing is the desire to transition 
Phobos in addition to some flawed ideology. (One of the other 
constraints was that you should be able to zip up the directory 
of the package and have it all together, hence using 
dir/package.d instead of just dir.d. But this would have worked 
anyway if not for the inconsistent design flaw of requiring the 
file to be called package.d in the first place! And with this if 
you compile it separately vs compiling it together you get 
totally different results. It really is just a *terrible* design.)
Nov 04 2022
parent Guillaume Piolat <first.last spam.org> writes:
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 should really be "mylib.api", 
because why import the private symbols.
Nov 04 2022
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
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.algorithm` instead of `import std.algorithm.sorting` (or 
whatever).

One alternative was to call the new things like 
`std.algorithm_parts.sorted` but this name a little ugly and 
people would be less likely to transition to it.

The failure of this scheme though is that the package.d design is 
braindead and broke things anyway as people updated and it 
brought about other various bugs down the line. It was possible 
to do it well but it wasn't.
Nov 04 2022
parent Steven Schveighoffer <schveiguy gmail.com> writes:
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 user code that still said `import std.algorithm` instead of 
 `import std.algorithm.sorting` (or whatever).
 
 One alternative was to call the new things like 
 `std.algorithm_parts.sorted` but this name a little ugly and people 
 would be less likely to transition to it.


It still didn't work. I almost always just do `import std.algorithm;`. 
Not worth my time to look up which specific algorithm submodule has the 
thing I need, especially when most likely std.algorithm.foo is going to 
import std.algorithm.bar anyway.

-Steve
Nov 04 2022
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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. This 
 is incredibly common, for instance, in Visual Studio Code, when 
 you hit CTRL+P and type the file name, nope, you will need to 
 write path/to/folder/package.d, beyond that, when you search 
 package.d there will be so many files with the same name.

 2. As being an exception to how the module system works, this 
 has already caused me a few headaches (inexplicable bugs), that 
 happens with symbols aliasing, when the time it happened, I had 
 no idea on what it could be and I don't even remember how I 
 solved, instead, I only knew it was related to package.d.

 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 Linker does not show the full directory of the 
 libraries/object files that caused this clash, not even the 
 symbol!

 The duplicate symbol currently only happens in MSVC Linker, 
 which makes me think if the bug is in the D language or the 
 linker itself, as on LLD this does not happen.
 So, my current advice is always try making your file names 
 unique, this will bring a much better debuggability in your 
 project.


i use that feature a lot, just search with the folder name, then 
"package"

https://i.imgur.com/cHb7isl.png

it's also very useful to avoid having all of your code in a giant 
unreadable single file

it's also very useful to avoid using dub.. just an import path to 
the folder and that's it

https://i.imgur.com/Wy6WOXK.png

also very useful when you want to simplify using importc, put 
your c files under the c folder, and the package.d, public import 
the c files, and you can put some helper code in D there, very 
nice to have
Nov 04 2022
parent reply Hipreme <msnmancini hotmail.com> writes:
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:

 1. You won't be able to find your module by the file name. 
 This is incredibly common, for instance, in Visual Studio 
 Code, when you hit CTRL+P and type the file name, nope, you 
 will need to write path/to/folder/package.d, beyond that, when 
 you search package.d there will be so many files with the same 
 name.

 2. As being an exception to how the module system works, this 
 has already caused me a few headaches (inexplicable bugs), 
 that happens with symbols aliasing, when the time it happened, 
 I had no idea on what it could be and I don't even remember 
 how I solved, instead, I only knew it was related to package.d.

 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 Linker does not show the full directory of the 
 libraries/object files that caused this clash, not even the 
 symbol!

 The duplicate symbol currently only happens in MSVC Linker, 
 which makes me think if the bug is in the D language or the 
 linker itself, as on LLD this does not happen.
 So, my current advice is always try making your file names 
 unique, this will bring a much better debuggability in your 
 project.


 i use that feature a lot, just search with the folder name, 
 then "package"

 https://i.imgur.com/cHb7isl.png

 it's also very useful to avoid having all of your code in a 
 giant unreadable single file

 it's also very useful to avoid using dub.. just an import path 
 to the folder and that's it

 https://i.imgur.com/Wy6WOXK.png

 also very useful when you want to simplify using importc, put 
 your c files under the c folder, and the package.d, public 
 import the c files, and you can put some helper code in D 
 there, very nice to have



I believe that needing to write `package.d` manually is pretty 
useless. Most of the time it means "import everything from this 
directory". The only real usage that helped me is when I needed 
to create a `version(Release) import something.opt; else 
version(Debug) import something.hotload;` basically.

But that does not really require package.d.
Those historic issues that Adam said are the real cause of their 
current design.

Take into account how would you do it in Java. `import 
mypackage.*;` is how it was done, and I haven't never had any 
problem doing this, and this is pretty descriptive.

package.d feels a lot more Haxe's `import.hx`, but it has a main 
difference that import.hx is a REAL special file that changes a 
bit on what happens on your source files. They are automatically 
included in its dir/subdir (think of a per directory object.d).

The problem is that I'm not saying package.d is worthless, but it 
is a pool of bugs in the language that needs a real fix and only 
that post has already showed 4 bugs people have had. (Although I 
still don't like searching files by package.d, it is counter 
intuitive).
Nov 05 2022
parent ryuukk_ <ryuukk.dev gmail.com> writes:
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 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 
 Code, when you hit CTRL+P and type the file name, nope, you 
 will need to write path/to/folder/package.d, beyond that, 
 when you search package.d there will be so many files with 
 the same name.

 2. As being an exception to how the module system works, this 
 has already caused me a few headaches (inexplicable bugs), 
 that happens with symbols aliasing, when the time it 
 happened, I had no idea on what it could be and I don't even 
 remember how I solved, instead, I only knew it was related to 
 package.d.

 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 Linker does not show the full directory of the 
 libraries/object files that caused this clash, not even the 
 symbol!

 The duplicate symbol currently only happens in MSVC Linker, 
 which makes me think if the bug is in the D language or the 
 linker itself, as on LLD this does not happen.
 So, my current advice is always try making your file names 
 unique, this will bring a much better debuggability in your 
 project.


 i use that feature a lot, just search with the folder name, 
 then "package"

 https://i.imgur.com/cHb7isl.png

 it's also very useful to avoid having all of your code in a 
 giant unreadable single file

 it's also very useful to avoid using dub.. just an import path 
 to the folder and that's it

 https://i.imgur.com/Wy6WOXK.png

 also very useful when you want to simplify using importc, put 
 your c files under the c folder, and the package.d, public 
 import the c files, and you can put some helper code in D 
 there, very nice to have



 I believe that needing to write `package.d` manually is pretty 
 useless. Most of the time it means "import everything from this 
 directory". The only real usage that helped me is when I needed 
 to create a `version(Release) import something.opt; else 
 version(Debug) import something.hotload;` basically.

 But that does not really require package.d.
 Those historic issues that Adam said are the real cause of 
 their current design.

 Take into account how would you do it in Java. `import 
 mypackage.*;` is how it was done, and I haven't never had any 
 problem doing this, and this is pretty descriptive.

 package.d feels a lot more Haxe's `import.hx`, but it has a 
 main difference that import.hx is a REAL special file that 
 changes a bit on what happens on your source files. They are 
 automatically included in its dir/subdir (think of a per 
 directory object.d).

 The problem is that I'm not saying package.d is worthless, but 
 it is a pool of bugs in the language that needs a real fix and 
 only that post has already showed 4 bugs people have had. 
 (Although I still don't like searching files by package.d, it 
 is counter intuitive).


oh i am with you, i just wanted to point out few usecase in case 
someone would want to improve/remove/change package.d 
functionality
Nov 05 2022
prev sibling next sibling parent Salih Dincer <salihdb hotmail.com> writes:
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://forum.dlang.org/post/kmgwcapkusvoxqapxrib forum.dlang.org

SDB 79
Nov 05 2022
prev sibling parent Dennis <dkorpel gmail.com> writes:
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 Linker does not show the full directory of the 
 libraries/object files that caused this clash, not even the 
 symbol!


Do you have a (reduced) example of this?
Nov 05 2022