• Vathix (13/13) Mar 21 2004 If there's a D source file in a package with the same name as the
• Andy Friesen (4/11) Mar 21 2004 But then the compiler would have no idea whether you're looking to
• Vathix (4/19) Mar 21 2004 I thought of that; looks like a name disaster reguardless.
• Phill (8/21) Mar 21 2004 Similar topic but different:
• J Anderson (11/22) Mar 22 2004 I would like it if D had some sort of default module ie this.d.
• J Anderson (7/15) Mar 22 2004 Actually I forgot, I've thought about this before. I came to the
• news.digitalmars.com (8/13) Mar 23 2004 The current compiler doesn't allow this:
• Ilya Minkov (5/18) Mar 22 2004 I would expect that to be somewhat bug-prone, but not seriously.
• Vathix (3/8) Mar 22 2004 Works for me.
• Ant (20/24) Mar 22 2004 I created a "module" to do it automatically.
• J C Calvarese (5/11) Mar 22 2004 Sounds like a great convention to me.
• Phill (6/24) Mar 22 2004 Is there any reason why you wouldnt want to do:
• Derek Parnell (7/9) Mar 22 2004 This is kind of like asking why would somebody have source files in a
• Phill (9/20) Mar 22 2004 geez, its a wonder all of the Java developers
• Derek Parnell (12/18) Mar 22 2004 Well that only goes to prove that Java coders are a lot better organised...
• Phill (16/35) Mar 23 2004 I dont know about D, but in Java you cant have dupilcate classes:(I dont
• Derjo Phar (35/55) Mar 23 2004 Ok, i've played around a bit now with modules and imports, and I feel th...
• Kris (13/36) Mar 23 2004 Just as an aside;
• Phill (12/56) Mar 23 2004 I see your point, and I also import the specific
• Phill (3/16) Mar 23 2004 woops

Vathix <vathix dprogramming.com> writes:

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

Andy Friesen <andy ikagames.com> writes:

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

Vathix <vathix dprogramming.com> writes:

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

"Phill" <phill pacific.net.au> writes:

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

J Anderson <REMOVEanderson badmama.com.au> writes:

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/

J Anderson <REMOVEanderson badmama.com.au> writes:

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/

"news.digitalmars.com" <jcesar phreaker.net> writes:

The current compiler doesn't allow this:

src/mymodule.d
src/mymodule/mod1.d
src/mymodule/mod2.d


"J Anderson" <REMOVEanderson badmama.com.au> escribió en el mensaje
news:c3nei8$n7r$1 digitaldaemon.com...
 J Anderson wrote:

(...)
 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.

(...)

Ilya Minkov <minkov cs.tum.edu> writes:

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.
 

Vathix <vathix dprogramming.com> writes:

 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

Ant <Ant_member pathlink.com> writes:

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 C Calvarese <jcc7 cox.net> writes:

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/

"Phill" <phill pacific.net.au> writes:

Is there any reason why you wouldnt want to do:

import    packagename.*;

?

Phill.


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c3mprf$2kgo$2 digitaldaemon.com...
 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.

"Derek Parnell" <Derek.Parnell psyc.ward> writes:

On Tue, 23 Mar 2004 15:58:51 +1100 (23/Mar/04 03:58:51 PM)
, Phill <phill pacific.net.au> wrote:

 Is there any reason why you wouldnt want to do:

 import    packagename.*;

This is kind of like asking why would somebody have source files in a  
folder that are not modules? I guess during development it is quite likely  
for somebody to have a few not-for-production-use files hanging around.

-- 
Derek

"Phill" <phill pacific.net.au> writes:

geez, its a wonder all of the Java developers
that exist can somehow get away with it.

Somehow it is possible to have other file
types in your Java packages and still

import packagename.*;

without any problems

Phill.


"Derek Parnell" <Derek.Parnell psyc.ward> wrote in message
news:opr5at2v1nu2m3b2 news.digitalmars.com...
 On Tue, 23 Mar 2004 15:58:51 +1100 (23/Mar/04 03:58:51 PM)
 , Phill <phill pacific.net.au> wrote:

 Is there any reason why you wouldnt want to do:

 import    packagename.*;

 This is kind of like asking why would somebody have source files in a
 folder that are not modules? I guess during development it is quite likely
 for somebody to have a few not-for-production-use files hanging around.

 --
 Derek

"Derek Parnell" <Derek.Parnell psyc.ward> writes:

On Tue, 23 Mar 2004 16:54:00 +1100 (23/Mar/04 04:54:00 PM)
, Phill <phill pacific.net.au> wrote:

 geez, its a wonder all of the Java developers
 that exist can somehow get away with it.

 Somehow it is possible to have other file
 types in your Java packages and still

 import packagename.*;

 without any problems

Well that only goes to prove that Java coders are a lot better organised  
than I am.

But seriously, maybe its just that I don't understand the import system  
enough yet. I would have thought that importing every file from a folder  
might cause a problem if two files had the same module name or function  
name defined. Some sort of ambiguity would need to be resolved if such an  
identifier were used without ornamentation. I should just shut up and try  
a few experiements first, eh?

-- 
Derek

"Phill" <phill pacific.net.au> writes:

"Derek Parnell" <Derek.Parnell psyc.ward> wrote in message
news:opr5axggvxu2m3b2 news.digitalmars.com...
 On Tue, 23 Mar 2004 16:54:00 +1100 (23/Mar/04 04:54:00 PM)
 , Phill <phill pacific.net.au> wrote:

 geez, its a wonder all of the Java developers
 that exist can somehow get away with it.

 Somehow it is possible to have other file
 types in your Java packages and still

 import packagename.*;

 without any problems

 Well that only goes to prove that Java coders are a lot better organised
 than I am.

 But seriously, maybe its just that I don't understand the import system
 enough yet. I would have thought that importing every file from a folder
 might cause a problem if two files had the same module name or function
 name defined. Some sort of ambiguity would need to be resolved if such an
 identifier were used without ornamentation.


I dont know about D, but in Java you cant have dupilcate classes:(I dont
believe that you can in
D either)

ie:
You cant have two

somepackage.someclass;
(Why would you want to anyway?)
And they couldnt possibly have the same filename
or one would overwrite the other.

as for methods, they shouldnt matter either because they are in a different
class.

I would have thought that D would be the same.

Is it not?

Phill.

"Derjo Phar" <not available.com> writes:

"Derek Parnell" <Derek.Parnell psyc.ward> wrote in message
news:opr5axggvxu2m3b2 news.digitalmars.com...
 On Tue, 23 Mar 2004 16:54:00 +1100 (23/Mar/04 04:54:00 PM)
 , Phill <phill pacific.net.au> wrote:

 geez, its a wonder all of the Java developers
 that exist can somehow get away with it.

 Somehow it is possible to have other file
 types in your Java packages and still

 import packagename.*;

 without any problems

 Well that only goes to prove that Java coders are a lot better organised
 than I am.

 But seriously, maybe its just that I don't understand the import system
 enough yet. I would have thought that importing every file from a folder
 might cause a problem if two files had the same module name or function
 name defined. Some sort of ambiguity would need to be resolved if such an
 identifier were used without ornamentation. I should just shut up and try
 a few experiements first, eh?

Ok, i've played around a bit now with modules and imports, and I feel that
any form of "import *" may lead to name clashes. The reason is that it is
possible to have two files that both contain the same 'module' statement.
When they are both imported, dmd will complain about a duplicate module
name.

But now I have another problem. It seems that in order to resolve name
clashes, the coder must qualify the identifier with the module name. This
makes sense. However, I'm sure the DMD is clear about what is the module
name. For example, if I have a file called 'im1.d' that looks like this ...

  module MOD1;

  class Foo
  {
    int x;

    this() { x = 1; }
  }

then I have a file that imports this file ...

  import im1;

  void main()
  {
    Foo f;

    f = new Foo;
  }

my question is, if I have to qualify the reference to Foo, why do I have to
use 'im1' as the module name rather than the 'MOD1' that is specified in the
module statement?

In other words, dmd accepts "im1.Foo" but rejects "MOD1.Foo". This seems odd
to me as the docs seem to say that if a module statement is missing, dmd
uses the file name as the default module name. Thus I read into this that if
the module statement is present, then dmd would use that name.

All I can see that the module statement does, is to form a part of the
internal (mangled) name for the OBJ file.


-- 
Derek

"Kris" <someidiot earthlink.net> writes:

Just as an aside;

I can't recall many particular reasons, but, it's been considered "poor
form" to use the Java import pkg.* syntax for quite some time (at least in
the circles I used to move within).

Several years of Java taught me to be explicit with imports, partly so that
maintainers and forgetful authors don't have to guess at what's actually
imported. Additionally, I've seen cases where extensions to the package
structure will break code because of name conflicts -- explicit import fixed
that every time.

- Kris

"Phill" <phill pacific.net.au> wrote in message
news:c3ojdi$2ohk$1 digitaldaemon.com...
 geez, its a wonder all of the Java developers
 that exist can somehow get away with it.

 Somehow it is possible to have other file
 types in your Java packages and still

 import packagename.*;

 without any problems

 Phill.


 "Derek Parnell" <Derek.Parnell psyc.ward> wrote in message
 news:opr5at2v1nu2m3b2 news.digitalmars.com...
 On Tue, 23 Mar 2004 15:58:51 +1100 (23/Mar/04 03:58:51 PM)
 , Phill <phill pacific.net.au> wrote:

 Is there any reason why you wouldnt want to do:

 import    packagename.*;

 This is kind of like asking why would somebody have source files in a
 folder that are not modules? I guess during development it is quite


likely
 for somebody to have a few not-for-production-use files hanging around.

 --
 Derek

"Phill" <phill pacific.net.au> writes:

I see your point, and I also import the specific
files also(not the whole package), unless there
is maybe 5 or 6 files in a particular package
that I want to import and then I prefer to import
the whole package for convienience sake.

I just thought Id make a suggestion.

Phill.


"Kris" <someidiot earthlink.net> wrote in message
news:c3otas$76r$1 digitaldaemon.com...
 Just as an aside;

 I can't recall many particular reasons, but, it's been considered "poor
 form" to use the Java import pkg.* syntax for quite some time (at least in
 the circles I used to move within).

 Several years of Java taught me to be explicit with imports, partly so

that
 maintainers and forgetful authors don't have to guess at what's actually
 imported. Additionally, I've seen cases where extensions to the package
 structure will break code because of name conflicts -- explicit import

fixed
 that every time.

 - Kris

 "Phill" <phill pacific.net.au> wrote in message
 news:c3ojdi$2ohk$1 digitaldaemon.com...
 geez, its a wonder all of the Java developers
 that exist can somehow get away with it.

 Somehow it is possible to have other file
 types in your Java packages and still

 import packagename.*;

 without any problems

 Phill.


 "Derek Parnell" <Derek.Parnell psyc.ward> wrote in message
 news:opr5at2v1nu2m3b2 news.digitalmars.com...
 On Tue, 23 Mar 2004 15:58:51 +1100 (23/Mar/04 03:58:51 PM)
 , Phill <phill pacific.net.au> wrote:

 Is there any reason why you wouldnt want to do:

 import    packagename.*;

 This is kind of like asking why would somebody have source files in a
 folder that are not modules? I guess during development it is quite


 likely
 for somebody to have a few not-for-production-use files hanging



around.
 --
 Derek

"Phill" <phill pacific.net.au> writes:

woops


"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