If there's a D source file in a package with the same name as the package, I think it would be nice to be able to omit that 2nd name in the import statement. Instead of:
import std.c.windows.windows;
You could use:
import std.c.windows;
And it knows to look for winodws.d inside.

This way the source with the package name would be the "include everything" file for the package (if you want one), instead of wildcard imports like Java. This seems cleaner to me, it allows you to omit the internal files -- import the files that are public.

-- 
Christopher E. Miller

Vathix wrote:
> If there's a D source file in a package with the same name as the package, I think it would be nice to be able to omit that 2nd name in the import statement. Instead of:
> import std.c.windows.windows;
> You could use:
> import std.c.windows;
> And it knows to look for winodws.d inside.

But then the compiler would have no idea whether you're looking to import std/c/windows.d or std/c/windows/windows.d

 -- andy

Andy Friesen wrote:

> Vathix wrote:
> 
>> If there's a D source file in a package with the same name as the package, I think it would be nice to be able to omit that 2nd name in the import statement. Instead of:
>> import std.c.windows.windows;
>> You could use:
>> import std.c.windows;
>> And it knows to look for winodws.d inside.
> 
> 
> But then the compiler would have no idea whether you're looking to import std/c/windows.d or std/c/windows/windows.d
> 
>  -- andy

I thought of that; looks like a name disaster reguardless.


-- 
Christopher E. Miller

Similar topic but different:

Is there a way to import the whole package like
in Java:

import std.c.windows.*;

If not I think it  would be good to have.

Phill.

"Vathix" <vathix@dprogramming.com> wrote in message news:c3kv7l$2o19$1@digitaldaemon.com...
> If there's a D source file in a package with the same name as the
> package, I think it would be nice to be able to omit that 2nd name in
> the import statement. Instead of:
> import std.c.windows.windows;
> You could use:
> import std.c.windows;
> And it knows to look for winodws.d inside.
>
> This way the source with the package name would be the "include everything" file for the package (if you want one), instead of wildcard imports like Java. This seems cleaner to me, it allows you to omit the internal files -- import the files that are public.
>
> --
> Christopher E. Miller

Vathix wrote:

> If there's a D source file in a package with the same name as the package, I think it would be nice to be able to omit that 2nd name in the import statement. Instead of:
> import std.c.windows.windows;
> You could use:
> import std.c.windows;
> And it knows to look for winodws.d inside.
>
> This way the source with the package name would be the "include everything" file for the package (if you want one), instead of wildcard imports like Java. This seems cleaner to me, it allows you to omit the internal files -- import the files that are public.
>
I would like it if D had some sort of default module ie this.d.

so when u types
import std.c.windows
it would load this.d

Of course there is that name clash that Andy pointed out but:
1) I think the current method of two windows.windows in std is confusing and bug prone anyway.
2) It could look for the file first before looking for the default.

-- 
-Anderson: http://badmama.com.au/~anderson/

I would expect that to be somewhat bug-prone, but not seriously.

I propose we simply have a convention that to import everything useful/public from a package, there should be a module named "all" in it.

-eye

Vathix schrieb:

> If there's a D source file in a package with the same name as the package, I think it would be nice to be able to omit that 2nd name in the import statement. Instead of:
> import std.c.windows.windows;
> You could use:
> import std.c.windows;
> And it knows to look for winodws.d inside.
> 
> This way the source with the package name would be the "include everything" file for the package (if you want one), instead of wildcard imports like Java. This seems cleaner to me, it allows you to omit the internal files -- import the files that are public.
> 

> I propose we simply have a convention that to import everything useful/public from a package, there should be a module named "all" in it.
> 
> -eye
> 

Works for me.

-- 
Christopher E. Miller

In article <c3mprf$2kgo$2@digitaldaemon.com>, Ilya Minkov says...
>
>I would expect that to be somewhat bug-prone, but not seriously.
>
>I propose we simply have a convention that to import everything useful/public from a package, there should be a module named "all" in it.
>
>-eye

I created a "module" to do it automatically.
It's as simple as it looks, of course.
(it's tied to leds, it allows to select the files that are to be included
I'm not sure if it's already release)

I created a similar one to generate import files
automatically from subdirectories.
(I think and example is better to try to describe it:
module foo.bar;

version(Win32)
{
   import win32.bar;
}
version(linux)
{
   import linux.bar;
}
it's also tied to leds and also allows to select the files
to include.)

Ant

J Anderson wrote:

> I would like it if D had some sort of default module ie this.d.
>
> so when u types
> import std.c.windows
> it would load this.d
>
> Of course there is that name clash that Andy pointed out but:
> 1) I think the current method of two windows.windows in std is confusing and bug prone anyway.
> 2) It could look for the file first before looking for the default.

Actually I forgot, I've thought about this before.  I came to the conclusion that all you really need to do is create a module with the same name in the folder (namespace) one level up, with the files you wish to include.

-- 
-Anderson: http://badmama.com.au/~anderson/

Ilya Minkov wrote:
> I would expect that to be somewhat bug-prone, but not seriously.
> 
> I propose we simply have a convention that to import everything useful/public from a package, there should be a module named "all" in it.
> 
> -eye

Sounds like a great convention to me.

-- 
Justin
http://jcc_7.tripod.com/d/