Hello everybody,

I am quite new to D and when learning how the packages and modules worked, it seemed strange to me that if one wanted to import whole packages one would have to create a module (for example a module called "All") and do public imports of every other module in the package.

While this approach works, it's quite painful to keep that module up to date, as people tend to forget to update the central module doing the public imports.

Now, I propose to extend the import declaration so that if only a
package is given, it imports all modules in that package.
For example "import std.c;" would import std.c.fenv, std.c.math,
std.c.process, std.c.stdargs, etc modules.

This approach would keep the code a bit easier to maintain as one wouldn't have to update the public imports module all the time.

What do you think? Could it be implemented in DMD?

Thanks in advance,
Mart Roosmaa

Mart Roosmaa wrote:
> Hello everybody,
> 
> I am quite new to D and when learning how the packages and modules
> worked, it seemed strange to me that if one wanted to import whole
> packages one would have to create a module (for example a module called
> "All") and do public imports of every other module in the package.
> 
> While this approach works, it's quite painful to keep that module up to
> date, as people tend to forget to update the central module doing the
> public imports.
> 
> Now, I propose to extend the import declaration so that if only a
> package is given, it imports all modules in that package.
> For example "import std.c;" would import std.c.fenv, std.c.math,
> std.c.process, std.c.stdargs, etc modules.
> 
> This approach would keep the code a bit easier to maintain as one
> wouldn't have to update the public imports module all the time.
> 
> What do you think? Could it be implemented in DMD?
> 
> Thanks in advance,
> Mart Roosmaa
> 

I've wanted this since I started using D. :P

Mart Roosmaa wrote:

> would keep the code a bit easier to maintain

Why do you want an import statement at all?

Mart Roosmaa wrote:
> Hello everybody,
> 
> I am quite new to D and when learning how the packages and modules
> worked, it seemed strange to me that if one wanted to import whole
> packages one would have to create a module (for example a module called
> "All") and do public imports of every other module in the package.
> 
> While this approach works, it's quite painful to keep that module up to
> date, as people tend to forget to update the central module doing the
> public imports.
> 
> Now, I propose to extend the import declaration so that if only a
> package is given, it imports all modules in that package.
> For example "import std.c;" would import std.c.fenv, std.c.math,
> std.c.process, std.c.stdargs, etc modules.
> 
> This approach would keep the code a bit easier to maintain as one
> wouldn't have to update the public imports module all the time.
> 
> What do you think? Could it be implemented in DMD?

What do you do about modules that really are intended to be implementation details rather than end-user code (aka private module)? What about packages containing a hierarchy of subpackages - do you import those recursively?

I would be more agreeable to the proposal if "import std.c" would be synononymous with "import std.c.all if it exists, otherwise import everything you can find under std.c".  That way the package maintainers still get to decide what consitutes 'all visible modules' of the package if they care to.

--bb

Karen Lanrap wrote:
> Mart Roosmaa wrote:
> 
>> would keep the code a bit easier to maintain
> 
> Why do you want an import statement at all?

The alternative being one file applications and libraries...

I'll take imports.

Bill Baxter wrote:
> Mart Roosmaa wrote:
>> Hello everybody,
>>
>> I am quite new to D and when learning how the packages and modules
>> worked, it seemed strange to me that if one wanted to import whole
>> packages one would have to create a module (for example a module called
>> "All") and do public imports of every other module in the package.
>>
>> While this approach works, it's quite painful to keep that module up to
>> date, as people tend to forget to update the central module doing the
>> public imports.
>>
>> Now, I propose to extend the import declaration so that if only a
>> package is given, it imports all modules in that package.
>> For example "import std.c;" would import std.c.fenv, std.c.math,
>> std.c.process, std.c.stdargs, etc modules.
>>
>> This approach would keep the code a bit easier to maintain as one
>> wouldn't have to update the public imports module all the time.
>>
>> What do you think? Could it be implemented in DMD?
> 
> What do you do about modules that really are intended to be implementation details rather than end-user code (aka private module)? What about packages containing a hierarchy of subpackages - do you import those recursively?
> 
> I would be more agreeable to the proposal if "import std.c" would be synononymous with "import std.c.all if it exists, otherwise import everything you can find under std.c".  That way the package maintainers still get to decide what consitutes 'all visible modules' of the package if they care to.
> 
> --bb

Sensible.

Kyle Furlong wrote:
> Bill Baxter wrote:
> 
>> Mart Roosmaa wrote:
>>
>>> Hello everybody,
>>>
>>> I am quite new to D and when learning how the packages and modules
>>> worked, it seemed strange to me that if one wanted to import whole
>>> packages one would have to create a module (for example a module called
>>> "All") and do public imports of every other module in the package.
>>>
>>> While this approach works, it's quite painful to keep that module up to
>>> date, as people tend to forget to update the central module doing the
>>> public imports.
>>>
>>> Now, I propose to extend the import declaration so that if only a
>>> package is given, it imports all modules in that package.
>>> For example "import std.c;" would import std.c.fenv, std.c.math,
>>> std.c.process, std.c.stdargs, etc modules.
>>>
>>> This approach would keep the code a bit easier to maintain as one
>>> wouldn't have to update the public imports module all the time.
>>>
>>> What do you think? Could it be implemented in DMD?
>>
>>
>> What do you do about modules that really are intended to be implementation details rather than end-user code (aka private module)? What about packages containing a hierarchy of subpackages - do you import those recursively?
>>
>> I would be more agreeable to the proposal if "import std.c" would be synononymous with "import std.c.all if it exists, otherwise import everything you can find under std.c".  That way the package maintainers still get to decide what consitutes 'all visible modules' of the package if they care to.
>>
>> --bb
> 
> 
> Sensible.

Agreed; although one could easily enough add 'package:' to the top of one's private modules, this comes at the price of symbols being unavailable to subpackages (in my opinion, this is a shortcoming of the package protection attribute).  Also, this may or may not play well with the presence of other protection attributes in the code (such as private members, or some single public class/interface).

-- Chris Nicholson-Sauls

Mart Roosmaa wrote:

> I am quite new to D and when learning how the packages and modules
> worked, it seemed strange to me that if one wanted to import whole
> packages one would have to create a module (for example a module called
> "All") and do public imports of every other module in the package.

I'm using the module.module syntax. As in: import wx.wx;

> While this approach works, it's quite painful to keep that module up to
> date, as people tend to forget to update the central module doing the
> public imports.

Well, if they forget that - they have other problems :-)

> Now, I propose to extend the import declaration so that if only a
> package is given, it imports all modules in that package.
> For example "import std.c;" would import std.c.fenv, std.c.math,
> std.c.process, std.c.stdargs, etc modules.

Or use the Java-like syntax, perhaps: "import std.c.*;" ?

--anders

Karen Lanrap schrieb:
> Why do you want an import statement at all?

I think you mean: Can't Mr. Compiler handle this task....?!

Björn

On Sat, 2006-10-28 at 11:42 +0900, Bill Baxter wrote:
> What do you do about modules that really are intended to be implementation details rather than end-user code (aka private module)? What about packages containing a hierarchy of subpackages - do you import those recursively?

Only the modules of that package will be loaded, not sub-packages, because that way all the potential name conflicts that could happen are avoided. Also, who would want to import ALL of the sub-packages of some package? Well, true, sometimes it's necessary, but most of the time it would be just an annoying feature.

As to not loading the private module, isn't it possible to use public/private on the module syntax? If not it could be extended to that. So then public modules would be accessible to all, protected modules to the modules package and sub-package modules. And finally, but not least private modules would be accessible only from the current package.

> I would be more agreeable to the proposal if "import std.c" would be synononymous with "import std.c.all if it exists, otherwise import everything you can find under std.c".  That way the package maintainers still get to decide what consitutes 'all visible modules' of the package if they care to.
> 
> --bb

In my opinion importing module name "all" by default is not such a good idea, because when someone imports that package, that someone would probably expect to get all the public modules in that package, not just a selection of them.

Mart