On 20 January 2016 at 18:37, deadalnix via Digitalmars-d <[email protected]> wrote: > On Wednesday, 20 January 2016 at 07:51:27 UTC, Manu wrote: >>> >>> 1. C++ has namespaces. They went and invented a whole 'nother thing >>> called modules. Evidently not even they think that modules and namespaces >>> are the same thing. >> >> >> You admit that modules supersede namespaces. We have modules, we use >> modules as standard practise. >> We don't need, or want, anything like namespaces. >> > > Maybe you don't, but I remain quite confident that being able to mimic the > structure of the C++ code in D is valuable. One can create a binding for a > library and have it usable in a similar fashion as it is in C++ from D.
How is that not possible with normal use of modules? > This makes it nice to people that already know the library, reduce the need > for specific doc for the binding, and makes maintenance of the binding much > easier as it has the same structure as the mapped C++ lib. I'm not sure how maintaining this structure has anything to do with namespaces. The only requirement for a lib to feel natural is to map each header to a module of the same name. When I look up the qt doc, I see: #include <widget.h> Which intuitively maps to: import qt.widget; The author requires some latitude in such mapping, eg: #include <SDL_image.h> Obviously unsavoury in D mapped verbatim, it would likely become: import sdl.image; You may consider this a drastic deviation from the doc, but I expect D users would universally prefer this. >>> 2. Multiple modules cannot have the same name in D. >> >> >> I'm not sure what situation you're imagining where modules would be >> created with the same names...? >> > > How do you plan to map C++'s standard lib ? One giant hundred of thousands > of line C++ file ? Surely it would map by file. #include <vector> -> import stl.vector; #include <map> -> import stl.map; #include <string> -> import stl.string; Perhaps 'stl' may be something else, 'std' is an unfortunate conflict with phobos, but this is unique to this case. >>> 7. Module semantics are independent of where they are imported. Not so >>> for namespaces. >>> >>> I.e. if modules were bludgeoned into being namespaces, >> >> >> Nobody has ever suggested anything like this. >> > > You did that quite a few time yourself. No, I really *really* didn't. It seems I have a habit of being completely misunderstood. > The WHOLE point of namespace in C++ is to be able to have symbol with the > same name and not conflict. D is extremely good at this already. > Now you could say, put them in different modules and use the modules to > disambiguate, but then you'd use the C++ library in quite a different way, > meaning you need to write new doc and make the work of the binding > maintainer harder. This doesn't make sense at all. How is that using it in a completely different way? I'd suggest it's the only possible way to make it feel the same. It's a no-brainer for the binding author, copy and rename .h files to .d, then regex until finished. What case is there where a C++ lib distributing its symbols naturally among modules named accordingly with the original include's would cause confusion when compared against the C++ docs? Doc says '#include <libname/feature.h>', I'll 'import libname.feature;' Nothing could be more natural than this. As a bonus, the project's C++ namespace 'libname' is already present in the fully qualified name, it's the top level package! No point repeating that as 'libname.feature.libname.symbol'.
