Hipreme's #4 Tip of the day - Don't use package.d
Hipreme
msnmancini at hotmail.com
Sat Nov 5 10:18:33 UTC 2022
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).
More information about the Digitalmars-d-learn
mailing list