digitalmars.D.bugs - [Issue 5005] New: Remove restrictions on module/package with same name.
- d-bugmail puremagic.com (34/34) Oct 06 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5005
- d-bugmail puremagic.com (11/11) Oct 06 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5005
- d-bugmail puremagic.com (27/27) Oct 06 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5005
- d-bugmail puremagic.com (29/29) Oct 06 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5005
- d-bugmail puremagic.com (44/44) Oct 06 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5005
- d-bugmail puremagic.com (30/30) Oct 07 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5005
http://d.puremagic.com/issues/show_bug.cgi?id=5005 Summary: Remove restrictions on module/package with same name. Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: ah08010-d yahoo.com PDT --- I've got a library, let's call it myLib. And I've declared it in the libs namespace, so that packages are of the form: libs.myLib.package I'd like to separate the details of the interface from the details of the implementation by creating a module, myLib.d, that imports the whole library interface: module myProgram; import libs.myLib; But I don't want a single D source file that eleventy-seven hundred lines of source, so I'd like my implementations to live in: // \file: source/libs/myLib/part1.d module libs.myLib.part1; // \file: source/libs/myLib/part2.d module libs.myLib.part2; Sadly, DMD2 currently prohibits this - module ... is in multiple packages ... Given that this seems like a pretty straightforward approach to maintaining clean code, I was surprised this isn't already supported. Anyway, please make it possible for a module to share a name with a package. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 06 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5005 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.cc As usual I don't fully understand what you are asking for. But can't you use some "public import" inside a module named "all"? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 06 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5005 PDT --- BOP, That approach would look like: libs/ ... + myLib/ ... | .... + all.d And it would (probably?) work. But I am trying to *hide* the details - I don't want user code to change if I elect to split a module into implemenation parts. So I'd like to start by coding libs/ ... + myLib.d And then later, when it grows too big, change to: libs/ ... | myLib.d ... | myLib/ ... | .... | part1.d ... | .... | part2.d And have the user code none the wiser. If you'd like to see a real-world example of why this is a good idea, have a look at the std.*.d files. A bunch of them are already straining at the seams with unrelated classes, templates, etc. And adding more unittests just makes the situation worse. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 06 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5005 Yao Gómez <yao.gomez gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yao.gomez gmail.com voted++ I wanted to have this exactly behavior in my date and time library, which is a port from Boost date_time, and have an humongous quantity of modules/files and functionality. For example, I have the following modules: --- yao.datetime.core; yao.datetime.date; yao.datetime.time; yao.datetime.localtime; yao.datetime.timezone; yao.datetime.iso8601; ... etc ... --- Although is perfectly valid to import one specific module if you want only the functionality of said module, it would be great if, to import all of the date and time facilites, I could create a module called yao.datetime, with just public imports of all of the above modules. Granted, I can use bearophile's suggestion of yao.datetime.all, but for me just using yao.datetime looks way better. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 06 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5005 Nick Sabalausky <cbkbbejeap mailinator.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbkbbejeap mailinator.com 18:23:30 PDT --- AUIU, the suggestion is to be able to take this: ------------------ // File libs/fizbarlib.d module libs.fizbarlib; void fiz() {} void bar() {} ------------------ And turn it into this: ------------------ // File libs/fizbarlib.d module libs.fizbarlib; public import libs.fizbarlib.fiz; public import libs.fizbarlib.bar; // File libs/fizbarlib/fiz.d module libs.fizbarlib.fiz; void fiz() {} // File libs/fizbarlib/bar.d module libs.fizbarlib.bar; void bar() {} ------------------ That does sound like a good idea. In the meantime, I'd like to suggest this as a workaround: ------------------ // File libs/fizbarlib.d module libs.fizbarlib; public import libs.fizbarlib_impl.fiz; public import libs.fizbarlib_impl.bar; // File libs/fizbarlib_impl/fiz.d module libs.fizbarlib_impl.fiz; void fiz() {} // File libs/fizbarlib_impl/bar.d module libs.fizbarlib_impl.bar; void bar() {} ------------------ That should achieve the same goal, albeit perhaps not quite as nicely. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 06 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5005 PDT --- Nick, Your understanding is correct. I want to be able to hide the implementation of the module/package from users of the module/package, by keeping the same name. Your suggestion, however, fails in real life. The problem with the _impl approach (which is *exactly* - down to the spelling - what I tried first) is that it fails for any kind of complex structure, where more than one _impl is required. ==== example ==== lib.mylib.sublib.foo becomes lib.mylib_impl.sublib_impl.foo and has to import lib.mylib_impl.something and lib.mylib_impl.sublib_impl.otherthing ========== The approach suggested by bearophile is (pardon the pun) bearable, since it permits the internal parts to maintain their correct names at the cost of having to change the caller code. This is the "worse" solution in terms of making the use of the library opaque, but the "better" solution in terms of making it possible to manipulate the source code with a "dumb" script: perl -pi.bak -e "s/lib.mylib;/lib.mylib.all;/" $file (The fact that I have to manipulate the code with a dumb shell script is evidence to me of why this is a good enhancement. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 07 2010