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


--- Comment #0 from Austin Hastings <ah08010-d@yahoo.com> 2010-10-06 13:44:33 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5005


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2010-10-06 13:51:50 PDT ---
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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5005



--- Comment #2 from Austin Hastings <ah08010-d@yahoo.com> 2010-10-06 14:23:59 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: -------

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


--- Comment #3 from Yao Gómez <yao.gomez@gmail.com> 2010-10-06 14:38:49 PDT ---
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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5005


Nick Sabalausky <cbkbbejeap@mailinator.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbkbbejeap@mailinator.com


--- Comment #4 from Nick Sabalausky <cbkbbejeap@mailinator.com> 2010-10-06 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5005



--- Comment #5 from Austin Hastings <ah08010-d@yahoo.com> 2010-10-07 07:44:01 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: -------