Re: Hipreme's #4 Tip of the day - Don't use package.d
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?
Re: Hipreme's #4 Tip of the day - Don't use package.d
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/kmgwcapkusvoxqapx...@forum.dlang.org SDB@79
Re: Hipreme's #4 Tip of the day - Don't use package.d
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
Re: Hipreme's #4 Tip of the day - Don't use package.d
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).
Re: Hipreme's #4 Tip of the day - Don't use package.d
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
Re: Hipreme's #4 Tip of the day - Don't use package.d
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.
Re: Hipreme's #4 Tip of the day - Don't use package.d
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
Re: Hipreme's #4 Tip of the day - Don't use package.d
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.)
Re: Hipreme's #4 Tip of the day - Don't use 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 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.
Re: Hipreme's #4 Tip of the day - Don't use package.d
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 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
Re: Hipreme's #4 Tip of the day - Don't use package.d
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?
Re: Hipreme's #4 Tip of the day - Don't use package.d
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.
Re: Hipreme's #4 Tip of the day - Don't use package.d
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.
Re: Hipreme's #4 Tip of the day - Don't use package.d
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.
Re: Hipreme's #4 Tip of the day - Don't use package.d
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...)
Re: Hipreme's #4 Tip of the day - Don't use 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 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.
Re: Hipreme's #4 Tip of the day - Don't use package.d
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?
Re: Hipreme's #4 Tip of the day - Don't use package.d
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.
