On 03.03.2016 07:53, Sebastien Alaiwan wrote:
However, using global package names means you're relying on the library providers to avoid conflicts, in their package names, although they might not even know each other. Which basically implies to always put your name / company name in your package name, like "import alaiwan.lib_algo.array2d;", or "import apple.lib_algo.array2d". Or rename my "lib_algo" to something meaningless / less common, like "import diamond.array2d" (e.g Derelict, Pegged, imaged, etc.).
Yeah, that's a thing. For published libraries one should choose a unique name.
I think reverse domain name notation [1] is a convention for exactly that. As far as I know, not many D projects do that, though, if any at all. But it would be a way out if collisions become a problem.
Also, dub/code.dlang.org plays a role here, as people may assume that a name is free as long as it's not on the dub list. This works well when dub is indeed the one place to go for libraries. If it isn't, then things may get messy.
If, unfortunately, I happen to run into a conflict, i.e my project uses two unrelated libraries sharing a name for their top-level namespace, there's no way out for me, right? (Except relying on shared objects to isolate symbols)
Yeah, as far as I can tell, you would have to change the name of one of the libraries, and update all related module declarations and imports.
[1] https://en.wikipedia.org/wiki/Reverse_domain_name_notation
