www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Importing packages

reply Mart Roosmaa <roosmaa gmail.com> writes:
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
Oct 27 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
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
Oct 27 2006
prev sibling next sibling parent reply Karen Lanrap <karen digitaldaemon.com> writes:
Mart Roosmaa wrote:

 would keep the code a bit easier to maintain

Why do you want an import statement at all?
Oct 27 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
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.
Oct 27 2006
prev sibling parent reply BLS <nanali wanadoo.fr> writes:
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
Oct 28 2006
parent Karen Lanrap <karen digitaldaemon.com> writes:
BLS wrote:

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

No. I wanted to know, what justification the OP gives for the existence of import statements. If he would have given "avoiding name collisions" then he would have been in the immediate need to show, that name collisions in packages cannot happen, which seems to be an impossible mission. There might be other arguments, but all would be broken, as soon as one starts to allow for pruning the hierarchy. The ultimate question after such a start would be: Why do I have to write "import *;"?
Oct 28 2006
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Oct 27 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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.
Oct 27 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Oct 28 2006
prev sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
How about an attibute to the 'module' statement. E.g. public:

file mypackage/mymod1.d:
public module mypackage.mymod1;

file mypackage/mymod2.d:
module mypackage.mymod2;


the import with a star, does now an import of all modules in the
package, which have a 'public' module statement.

file main.d:
import mypackage.*; // imports mypackage.mymod
Oct 28 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Oct 28 2006
prev sibling next sibling parent Mart Roosmaa <roosmaa gmail.com> writes:
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
Oct 28 2006
prev sibling next sibling parent Mart Roosmaa <roosmaa gmail.com> writes:
On Sat, 2006-10-28 at 12:39 +0200, Frank Benoit (keinfarbton) wrote:
 the import with a star, does now an import of all modules in the
 package, which have a 'public' module statement.

I'd say that importing with an asterisk is a bad practice, because it hints, that the user could write something like this: import package.*ule Or even: import pack*.*ul*.* So, I must still insist on using just the package name and not the Java style asterisk. Mart
Oct 28 2006
prev sibling parent Mike Parker <aldacron71 yahoo.com> writes:
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?

Even though Java allows this, it is generally regarded as poor practice. I have often seen coding standards that forbid it, requiring each class used to be imported explicitly. Explicit import of each class greatly reduces the chance of naming collisions, but also serves as a sort of documentation on which classes from a package are used in any given source file. Perhaps the most well-known examples of this are the Apache projects. If you look through the source to any Apache project, you won't find the use of .* imports. If this were to be implemented in D, I would prefer to see the java syntax of mypackage.*, or something similar. Otherwise, it isn't immediately obvious by reading the code if an entire package is being imported or not. Consider this: import foo.bar.blue; Under your proposal, is blue a module or a package? It is assumed that users of a library would know the difference, since they are using the library anyway. But when it comes to code reviews, library examples, or any other situation where people not intimate with the package structure need to see the code, it adds to the learning curve and could cause confusion. Using the Java syntax, import foo.bar.*, makes it clear that all modules in bar are being imported. I wouldn't use it myself, but I would only object to such a feature if implemented as you propose. Having an explicit syntax for package import, such as .*, would be okay. Though I'm of the opinion that use of it would reduce code quality.
Oct 28 2006