Importing packages

[Mart Roosmaa]

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