www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5005] New: Remove restrictions on module/package with same name.

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
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