• Mart Roosmaa (17/17) Oct 27 2006 Hello everybody,
• Kyle Furlong (2/26) Oct 27 2006 I've wanted this since I started using D. :P
• Karen Lanrap (2/3) Oct 27 2006 Why do you want an import statement at all?
• Kyle Furlong (3/8) Oct 27 2006 The alternative being one file applications and libraries...
• BLS (3/4) Oct 28 2006 I think you mean: Can't Mr. Compiler handle this task....?!
• Karen Lanrap (10/11) Oct 28 2006 No. I wanted to know, what justification the OP gives for the
• Bill Baxter (11/31) Oct 27 2006 What do you do about modules that really are intended to be
• Kyle Furlong (2/36) Oct 27 2006 Sensible.
• Chris Nicholson-Sauls (7/48) Oct 28 2006 Agreed; although one could easily enough add 'package:' to the top of on...
• Mart Roosmaa (17/28) Oct 28 2006 Only the modules of that package will be loaded, not sub-packages,
• Frank Benoit (keinfarbton) (9/9) Oct 28 2006 How about an attibute to the 'module' statement. E.g. public:
• Mart Roosmaa (9/11) Oct 28 2006 I'd say that importing with an asterisk is a bad practice, because it
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (5/16) Oct 28 2006 Well, if they forget that - they have other problems :-)
• Mike Parker (25/45) Oct 28 2006 Even though Java allows this, it is generally regarded as poor practice....

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

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

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?

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.

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

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 *;"? 

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

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.

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

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

"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

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

=?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

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.