www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why can't we put import in functions.

reply Yang Bo <pop.atry gmail.com> writes:
We can put "using namesapce" in any place in C++. Why not do the same
way in D?
Oct 15 2007
next sibling parent James Dennett <jdennett acm.org> writes:
Yang Bo wrote:

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


Not true for C++.  "using namespace" is invalid at class scope.
It works at namespace scope or block scope.  (It's a minor wart
on C++.  One of many.)

-- James
Oct 15 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Yang Bo Wrote:


 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


mixin(import(FILENAME));

You may need a compile-time function to strip the module declaration and be
wary of forward references.
Oct 15 2007
next sibling parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Robert Fraser Wrote:


 Yang Bo Wrote:
 

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


 
 mixin(import(FILENAME));
 
 You may need a compile-time function to strip the module declaration and be
wary of forward references.


Its practices like this that will result it someone writing D++ or E or
switching to something else entirely. Ugly ugly ugly. Do not promote.

Bruce.
Oct 16 2007
parent Brad Roberts <braddr puremagic.com> writes:
Bruce Adams wrote:

 Robert Fraser Wrote:
 

 Yang Bo Wrote:


 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


 mixin(import(FILENAME));

 You may need a compile-time function to strip the module declaration and be
wary of forward references.


 
 Its practices like this that will result it someone writing D++ or E or
 switching to something else entirely. Ugly ugly ugly. Do not promote.
 
 Bruce.


Aside from the overt ugliness of the suggestion, it's also significantly 
different.

C++'s "using namespace" and D's 'import' convey symbol visibility.  D's 
mixin(import(filename)) is direct inclusion of code, implementation and 
all.  That mixin syntax is the equivalent of C/C++'s #include 
preprocessor token.

Later,
Brad
Oct 16 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Robert Fraser wrote:

 Yang Bo Wrote:
 

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


 
 mixin(import(FILENAME));
 
 You may need a compile-time function to strip the module declaration and be
wary of forward references.


That doesn't work: any (non-instance) variable definition of the 
imported module would be duplicated.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Yang Bo wrote:

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


Yes it is lacking.  Definitely on my top ten features list for D.

--bb
Oct 15 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Bill Baxter wrote:

 Yang Bo wrote:

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


 
 Yes it is lacking.  Definitely on my top ten features list for D.
 
 --bb


It's particularly annoying that you can't use import in unittest{} blocks.
Oct 15 2007
next sibling parent reply Yang Bo <pop.atry gmail.com> writes:
Don Clugston дµÀ:

 Bill Baxter wrote:

 Yang Bo wrote:

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


 Yes it is lacking.  Definitely on my top ten features list for D.

 --bb


 It's particularly annoying that you can't use import in unittest{} blocks.


And, why do we need to write static import? Compiler should look for .d
files automaticly as Java.
Oct 16 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Yang Bo wrote:

 Don Clugston дµÀ:

 Bill Baxter wrote:

 Yang Bo wrote:

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


 Yes it is lacking.  Definitely on my top ten features list for D.

 --bb


 It's particularly annoying that you can't use import in unittest{} blocks.


 
 And, why do we need to write static import? Compiler should look for .d
 files automaticly as Java.


Umm... what exactly are you saying?  'static import' does the same thing
as 'import' except it doesn't expose the contents of the module into
global scope, just the FQN.

And neither have an effect on how the compiler looks for .d files.

I have a feeling you want D to compile like Java does; specify the first
file and the compiler pulls in all the dependant modules.  There have
been various proposals to do this before, however Walter feels the
advantages outweigh the inconvenience.  Also, since we have tools like
dsss and bud, it's not really an issue.

	-- Daniel
Oct 16 2007
prev sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Don Clugston wrote:

 Bill Baxter wrote:

 Yang Bo wrote:

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


 Yes it is lacking.  Definitely on my top ten features list for D.

 --bb


 It's particularly annoying that you can't use import in unittest{} blocks.


I see lots of code that looks like this:

// Dont pollute module with unittest only symbols
debug(UnitTesting) import testingdepedencies;

unittest
{
    ...
}
Oct 16 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kyle Furlong wrote:

 Don Clugston wrote:

 Bill Baxter wrote:

 Yang Bo wrote:

 We can put "using namesapce" in any place in C++. Why not do the same
 way in D?


 Yes it is lacking.  Definitely on my top ten features list for D.

 --bb


 It's particularly annoying that you can't use import in unittest{} blocks.


 
 I see lots of code that looks like this:
 
 // Dont pollute module with unittest only symbols
 debug(UnitTesting) import testingdepedencies;
 
 unittest
 {
     ...
 }


I started doing this bit of verbose silliness.

version(Unittest) {
    import some.module.needed.for.tests;
}
unittest {
    /// tests....

    version(Unittest) {} else {
        static assert(false, "<filename>.d: This unittest must be run
with -version=Unittest");
    }
}
Oct 16 2007
parent reply Henning Hasemann <hhasemann web.de> writes:
I came to (nearly) entirely drop unittests and instead make "module
tests" where I compile each module into a binary and run it.

It goes like this:

module foo;
import bar;

// Class defitions etc...

version(module_test_foo) {
  import test_dep;
  void main() {
    // test code
  }
}

I know it isnt particular prettier either, especially as you have to be
careful about reusing your object files and have a lot of extra
compiling to do for the tests. But on the other hand the modules
included can "see" which module is beeing tested and file some special
cases for it to test or whatever.

I also use an additional -version=module_test which in some places is
needed (in my code) to skip some initialization functions that
otherwisely might "bite" with the main.

Also note that this is for library code where there would be no main()
at all, so it wouldnt be testable without having an extra main.

Henning

-- 
GPG Public Key:
http://gpg-keyserver.de/pks/lookup?op=get&search=0xDDD6D36D41911851
Oct 16 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.yk> writes:
Henning Hasemann Wrote:


 
 I came to (nearly) entirely drop unittests and instead make "module
 tests" where I compile each module into a binary and run it.
 
 It goes like this:
 
 module foo;
 import bar;
 
 // Class defitions etc...
 
 version(module_test_foo) {
   import test_dep;
   void main() {
     // test code
   }
 }
 
 I know it isnt particular prettier either, especially as you have to be
 careful about reusing your object files and have a lot of extra
 compiling to do for the tests. But on the other hand the modules
 included can "see" which module is beeing tested and file some special
 cases for it to test or whatever.
 
 I also use an additional -version=module_test which in some places is
 needed (in my code) to skip some initialization functions that
 otherwisely might "bite" with the main.
 
 Also note that this is for library code where there would be no main()
 at all, so it wouldnt be testable without having an extra main.
 
 Henning
 
 -- 
 GPG Public Key:
 http://gpg-keyserver.de/pks/lookup?op=get&search=0xDDD6D36D41911851


I tend to follow a cppunit like model. For every class I create a test class
which has a main. This gets all your unittest stuff into a separate file from
the implementation so it doens't get too big. 

Regards,

Bruce.
Oct 16 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:

 Henning Hasemann Wrote:
 

 I came to (nearly) entirely drop unittests and instead make "module
 tests" where I compile each module into a binary and run it.

 It goes like this:

 module foo;
 import bar;

 // Class defitions etc...

 version(module_test_foo) {
   import test_dep;
   void main() {
     // test code
   }
 }

 I know it isnt particular prettier either, especially as you have to be
 careful about reusing your object files and have a lot of extra
 compiling to do for the tests. But on the other hand the modules
 included can "see" which module is beeing tested and file some special
 cases for it to test or whatever.

 I also use an additional -version=module_test which in some places is
 needed (in my code) to skip some initialization functions that
 otherwisely might "bite" with the main.

 Also note that this is for library code where there would be no main()
 at all, so it wouldnt be testable without having an extra main.

 Henning

 -- 
 GPG Public Key:
 http://gpg-keyserver.de/pks/lookup?op=get&search=0xDDD6D36D41911851


 
 I tend to follow a cppunit like model. For every class I create a test class
which has a main. This gets all your unittest stuff into a separate file from
the implementation so it doens't get too big. 


Putting unittests in a separate file also has the advantage of enabling 
you to detect errors in access attributes (As in "oops! That wasn't 
supposed to be private!").


--bb
Oct 16 2007