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