Hey, I'd like to know why the "import whatever.* " statement hasn't been included in the language yet!

Isn't it faster & cleaner to use, let's say,

import randomlib.*;

when we need to import about all those modules, instead of doing it separately like nowadays it's done, like this?

import randomlib.Keyboard;
import randomlib.Screen;
import randomlib.Headphones;
import randomlib.Mouse;

Id wrote:

> Hey, I'd like to know why the "import whatever.* " statement hasn't been
> included in the language yet!
> 
> Isn't it faster & cleaner to use, let's say,
> 
> import randomlib.*;
> 
> when we need to import about all those modules, instead of doing it separately
> like nowadays it's done, like this?
> 
> import randomlib.Keyboard;
> import randomlib.Screen;
> import randomlib.Headphones;
> import randomlib.Mouse;

I'm not sure if I'd like this.  Sure it would be more convenient, but just assume for a moment that someday down the road randomlib gets an overhaul and adds 10 more modules that I don't need.  The wildcard semantics would automatically include all that stuff even if I wasn't aware of a change.


Sean

Yeah; I remember reading a few years ago that the Java community frowned upon such practice; for the same reason you mention.

"Sean Kelly" <sean@f4.ca> wrote in message news:cg6bca$12rg$2@digitaldaemon.com...
> Id wrote:
>
> > Hey, I'd like to know why the "import whatever.* " statement hasn't been included in the language yet!
> >
> > Isn't it faster & cleaner to use, let's say,
> >
> > import randomlib.*;
> >
> > when we need to import about all those modules, instead of doing it
separately
> > like nowadays it's done, like this?
> >
> > import randomlib.Keyboard;
> > import randomlib.Screen;
> > import randomlib.Headphones;
> > import randomlib.Mouse;
>
> I'm not sure if I'd like this.  Sure it would be more convenient, but just assume for a moment that someday down the road randomlib gets an overhaul and adds 10 more modules that I don't need.  The wildcard semantics would automatically include all that stuff even if I wasn't aware of a change.
>
>
> Sean

"Id" <Id_member@pathlink.com> wrote in message news:cg6apb$12o9$1@digitaldaemon.com...
> Hey, I'd like to know why the "import whatever.* " statement hasn't been included in the language yet!

>
> Isn't it faster & cleaner to use, let's say,
>
> import randomlib.*;
>
> when we need to import about all those modules, instead of doing it separately like nowadays it's done, like this?
>
> import randomlib.Keyboard;
> import randomlib.Screen;
> import randomlib.Headphones;
> import randomlib.Mouse;


I don't know Walter's rationale for this, but there are plenty of reasons against doing things like that:

- leads to ambituities
- code dependencies are not instrumentable
- teaches sloppy habits
- precludes fine-grained selection of services from competing modules.
- makes writing a fat-free linker harder (or a linker that produces fat-free executables)
- introduces uncertainty with respect to static initialisers from logically unused modules

Id wrote:

> Hey, I'd like to know why the "import whatever.* " statement hasn't been
> included in the language yet!
> 
> Isn't it faster & cleaner to use, let's say,
> 
> import randomlib.*;
> 
> when we need to import about all those modules, instead of doing it separately
> like nowadays it's done, like this?
> 
> import randomlib.Keyboard;
> import randomlib.Screen;
> import randomlib.Headphones;
> import randomlib.Mouse;

It's a good thing to have, but the wrong way to do it, for reasons others have already explained.

Regardless, it's pretty irritating that we're forced to tack on some meaningless 'all' symbol on the end of some import path or other.

Python interprets a package's __init__ module (Python is big on __underscores__) to represent the package as a whole.  Something like this would be hugely useful. (multiple directories in the search path which happen to have the same name can be ignored on the grounds that it's weird and not usually helpful to do so)

'this.d' seems a logical choice, as it's otherwise an illegal module name, and D's tendancy to use it for special names makes it a logical analogue to __python__ :)

 -- andy

> Python interprets a package's __init__ module (Python is big on __underscores__) to represent the package as a whole.  Something like this would be hugely useful. (multiple directories in the search path which happen to have the same name can be ignored on the grounds that it's weird and not usually helpful to do so)
>
> 'this.d' seems a logical choice, as it's otherwise an illegal module name, and D's tendancy to use it for special names makes it a logical analogue to __python__ :)
>
>   -- andy

Or 'package.d'. This feature would be nice.

Id wrote:
> Hey, I'd like to know why the "import whatever.* " statement hasn't been
> included in the language yet!
> 
> Isn't it faster & cleaner to use, let's say,
> 
> import randomlib.*;
> 
> when we need to import about all those modules, instead of doing it separately
> like nowadays it's done, like this?
> 
> import randomlib.Keyboard;
> import randomlib.Screen;
> import randomlib.Headphones;
> import randomlib.Mouse;
> 

It might be faster to use, but it could get real annoying real quick because it is so ambiguous.

Why not just do
-------d file-------
module randomlib;

import Keyboard;
import Screen;
import Headphones;
import Mouse;
--------------------
-------d file-------
import randomlib; // looks better than import randomlib.*
--------------------

In article <cg6apb$12o9$1@digitaldaemon.com>, Id says...
>
>Hey, I'd like to know why the "import whatever.* " statement hasn't been included in the language yet!
>
>Isn't it faster & cleaner to use, let's say,
>
>import randomlib.*;
>
>when we need to import about all those modules, instead of doing it separately like nowadays it's done, like this?
>
>import randomlib.Keyboard;
>import randomlib.Screen;
>import randomlib.Headphones;
>import randomlib.Mouse;

I think that the * is more dangerous than useful. (Emotionally, I like the idea, but I think it'd create more problems than it'd solve.)

The problem is pretty easy to alleviate by having a convention that says a certain module imports the other modules in a package.

My favorite is all.d (short and self-explanatory). Another potential convention
is [package].d where [package] is the name of the package (did that make any
sense?).

Related wiki page: http://www.prowiki.org/wiki4d/wiki.cgi?BestPractices "Conventional Module Name for Importing All Modules in a Package"

jcc7

J C Calvarese wrote:

> The problem is pretty easy to alleviate by having a convention that says a
> certain module imports the other modules in a package.
> 
> My favorite is all.d (short and self-explanatory). Another potential convention
> is [package].d where [package] is the name of the package (did that make any
> sense?). 

Both of these are good conventions, but in the end, they're clumsy attempts to say something that the language explicitly forbids us from saying. :(

 -- andy

In article <cg6jcv$1889$1@digitaldaemon.com>, Andy Friesen says...
>
>J C Calvarese wrote:
>
>> The problem is pretty easy to alleviate by having a convention that says a certain module imports the other modules in a package.
>> 
>> My favorite is all.d (short and self-explanatory). Another potential convention
>> is [package].d where [package] is the name of the package (did that make any
>> sense?).
>
>Both of these are good conventions, but in the end, they're clumsy attempts to say something that the language explicitly forbids us from saying. :(

Agreed. Instead of /any/ of the following choices:

#    import whatever.all;
#    import whatever.this;
#    import whatever.whatever;

it would be nice, instead, to be able to do:

#    import whatever;

But - oh no - we can't have a file called "whatever.d" AND a directory called "whatever" in the same place at the same time.

Jeez, I /so/ wish this rule can be changed. Walter once said "it just wouldn't work", but that was all the explanation we got. I can envisage problems, but not insurmountable ones.

Arcane Jill