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

[ryuukk_]

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