www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - proposal: improved import declaration

reply eao197 <eao197 intervale.ru> writes:
	Hi!

The proposal is to allow writing:

import <module-root>.{<name>[,<name>...]};

For example, instead of:

import tango.io.Console;
import tango.io.Conduit;
import tango.io.FilePath;
import tango.io.FileSystem;
import tango.io.Stdout;

simply write:

import tango.io.{Console, Conduit, FilePath, FileSystem, Stdout};

-- 
Regards,
Yauheni Akhotnikau
May 29 2007
next sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
eao197 wrote:
 [...]
 import tango.io.{Console, Conduit, FilePath, FileSystem, Stdout};

I like Java's syntax better: import tango.io.*; It's not as precise, but once you import more than two or three modules, you might as well do the whole namespace. Dave
May 29 2007
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 29 May 2007 22:36:45 -0700, David B. Held wrote:

 eao197 wrote:
 [...]
 import tango.io.{Console, Conduit, FilePath, FileSystem, Stdout};

I like Java's syntax better: import tango.io.*; It's not as precise, but once you import more than two or three modules, you might as well do the whole namespace.

One problem I have with importing things that you don't actually use, is that it makes impact analysis a bit harder. In other words, if I change a module, what other modules might be effected by that change? One way to find out is to see which modules import the one you are planning to change. To say "import whatever.*" doesn't help me know which module the importing source actually uses. I know this is not an absolute or exact way of knowing the impact but it goes a long way towards it. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 30/05/2007 4:28:13 PM
May 29 2007
prev sibling parent eao197 <eao197 intervale.ru> writes:
On Wed, 30 May 2007 09:36:45 +0400, David B. Held  
<dheld codelogicconsulting.com> wrote:

 eao197 wrote:
 [...]
 import tango.io.{Console, Conduit, FilePath, FileSystem, Stdout};

I like Java's syntax better: import tango.io.*; It's not as precise, but once you import more than two or three modules, you might as well do the whole namespace.

I think it's better to have both improvements, because import some.really.big.package.* is not a good idea if I want only 3 or 5 modules from package with 20+ modules and deep hierarchy. -- Regards, Yauheni Akhotnikau
May 30 2007
prev sibling parent reply davidl <davidl 126.com> writes:
wait till macro is available

 	Hi!

 The proposal is to allow writing:

 import <module-root>.{<name>[,<name>...]};

 For example, instead of:

 import tango.io.Console;
 import tango.io.Conduit;
 import tango.io.FilePath;
 import tango.io.FileSystem;
 import tango.io.Stdout;

 simply write:

 import tango.io.{Console, Conduit, FilePath, FileSystem, Stdout};

-- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
May 30 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 30 May 2007 16:08:40 +0400, davidl <davidl 126.com> wrote:

 wait till macro is available

I'm in doubt that this will be possible to do by a macro. And I don't think it's a good idea to modify behaviour of 'import declaration' by a macro because it can make life too difficult to D-oriented build tools (like rebuild).
 The proposal is to allow writing:

 import <module-root>.{<name>[,<name>...]};

 For example, instead of:

 import tango.io.Console;
 import tango.io.Conduit;
 import tango.io.FilePath;
 import tango.io.FileSystem;
 import tango.io.Stdout;

 simply write:

 import tango.io.{Console, Conduit, FilePath, FileSystem, Stdout};


-- Regards, Yauheni Akhotnikau
May 30 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Something like this:

macro myImport (pkg, mods...) {
   foreach (m; mods) {
     import pkg.m ;
   }
}

myImport(tango.io, Console, Conduit, FilePath, FileSystem, Stdout);

And seeing as rebuild is based around the compiler's own frontend, where such
macros are 
defined and expanded, I imagine it should adapt to them quite readily.  Other
build 
utilities, on the other hand, might have some issue.  (Maybe it really is time
to provide 
at least simple support for this in the compiler...)

-- Chris Nicholson-Sauls


eao197 wrote:
 On Wed, 30 May 2007 16:08:40 +0400, davidl <davidl 126.com> wrote:
 
 wait till macro is available

I'm in doubt that this will be possible to do by a macro. And I don't think it's a good idea to modify behaviour of 'import declaration' by a macro because it can make life too difficult to D-oriented build tools (like rebuild).
 The proposal is to allow writing:

 import <module-root>.{<name>[,<name>...]};

 For example, instead of:

 import tango.io.Console;
 import tango.io.Conduit;
 import tango.io.FilePath;
 import tango.io.FileSystem;
 import tango.io.Stdout;

 simply write:

 import tango.io.{Console, Conduit, FilePath, FileSystem, Stdout};


--Regards, Yauheni Akhotnikau

May 30 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chris Nicholson-Sauls wrote:
 Something like this:
 
 macro myImport (pkg, mods...) {
   foreach (m; mods) {
     import pkg.m ;
   }
 }
 
 myImport(tango.io, Console, Conduit, FilePath, FileSystem, Stdout);
 
 And seeing as rebuild is based around the compiler's own frontend, where 
 such macros are defined and expanded, I imagine it should adapt to them 
 quite readily.  Other build utilities, on the other hand, might have 
 some issue.  (Maybe it really is time to provide at least simple support 
 for this in the compiler...)

Other build utilities should be able to easily support this sort of thing by parsing the output of "dmd -v -o-". (For GDC, use either "gdmd -v -o-" or "gdc -fsyntax-only -fd-verbose" instead) I have the following clause in one of my makefiles: --- # Generate dependency information %.d$(DEP_SUFFIX): Makefile echo Processing $*.d dmd -v -o- $*.d $(DFLAGS) \ | grep '^import ' \ | sed -e 's/.*(\(.*\))/\1/' \ | xargs echo "$*.d$(OBJ_SUFFIX) $ : $*.d " \ > $ --- The first (relevant) line invokes DMD as above. -v shows lots of info about the file being processed, -o- suppresses actual compilation. The grep filters down to just lines about imports. The sed command extracts the bit between parentheses (the file name of the imported module). The xargs line prepends some information for Make to it, converting it to a dependency rule; the object file and the dependency file depend on the original file + all imported modules. The output is saved to the dependency file. All dependency files are included into the makefile. This works quite nicely. I would imagine it'd work even better in build utilities that can use the complete power of D (or another high-level language) to parse the output instead of being restricted to (interpreted) shell commands. (And it wouldn't need all of the above steps, since they don't need to generate make-compatible syntax)
May 30 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 30 May 2007 18:23:02 +0400, Frits van Bommel  
<fvbommel REMwOVExCAPSs.nl> wrote:

 This works quite nicely. I would imagine it'd work even better in build  
 utilities that can use the complete power of D (or another high-level  
 language) to parse the output instead of being restricted to  
 (interpreted) shell commands. (And it wouldn't need all of the above  
 steps, since they don't need to generate make-compatible syntax)

Thanks for your example. I want to add support of D to my build tool which is written in Ruby. I think your approach can save me a lot of work in implementing dependency analyzer. -- Regards, Yauheni Akhotnikau
May 30 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
eao197 wrote:
 On Wed, 30 May 2007 18:23:02 +0400, Frits van Bommel 
 <fvbommel REMwOVExCAPSs.nl> wrote:
 
 This works quite nicely. I would imagine it'd work even better in 
 build utilities that can use the complete power of D (or another 
 high-level language) to parse the output instead of being restricted 
 to (interpreted) shell commands. (And it wouldn't need all of the 
 above steps, since they don't need to generate make-compatible syntax)

Thanks for your example. I want to add support of D to my build tool which is written in Ruby. I think your approach can save me a lot of work in implementing dependency analyzer.

It certainly made my life a lot easier when I found out '-v' showed imports (prior to that I grepped for 'import' statements, using sed to change '.' to '/' and adding '.d'...). And it got even better when it also started showing the filenames, since I had several '-I' parameters on the command line that would all have to be searched[1] to get it working just right. But now the compiler reports filenames it works perfectly without anything too hackish :). [1]: Which I didn't do by the way; I just assumed imports were from my main import path, which caused some trouble once in a while if a file located elsewhere was changed and I forgot to do a 'make rebuild' instead of 'make'...
May 30 2007