www.digitalmars.com         C & C++   DMDScript  

D - import package;

reply 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
Mar 21 2004
next sibling parent reply 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
Mar 21 2004
parent 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
Mar 21 2004
prev sibling next sibling parent "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

Mar 21 2004
prev sibling next sibling parent reply 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.

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/
Mar 22 2004
parent reply 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/
Mar 22 2004
parent "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.

Mar 23 2004
prev sibling next sibling parent reply 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.
 

Mar 22 2004
next sibling parent 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
Mar 22 2004
prev sibling next sibling parent 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
Mar 22 2004
prev sibling next sibling parent 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/
Mar 22 2004
prev sibling parent reply "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.


Mar 22 2004
parent reply "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
Mar 22 2004
parent reply "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

Mar 22 2004
next sibling parent reply "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
Mar 22 2004
next sibling parent "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.
Mar 23 2004
prev sibling parent "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
Mar 23 2004
prev sibling parent reply "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


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

 --
 Derek


Mar 23 2004
parent "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

 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

 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


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



 --
 Derek



Mar 23 2004
prev sibling parent "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

Mar 23 2004