www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why import statements are not allowed in function bodies (or any block of code)?

reply Leandro Lucarella <llucax gmail.com> writes:
Is there any good reason for not allowing import statements in function
bodies or any code block? I think it would be really useful for avoid
namespace polution, specially in unittests (it's really ugly to import
things a module will never use except for unittesting).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Long you live and high you fly
And smiles you'll give and tears you'll cry
And all you touch and all you see
Is all your life will ever be. 
Jan 27 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Leandro Lucarella wrote:
 Is there any good reason for not allowing import statements in function
 bodies or any code block? I think it would be really useful for avoid
 namespace polution, specially in unittests (it's really ugly to import
 things a module will never use except for unittesting).
 

Did someone already suggest using the version(UnitTest) workaround? I do remember hearing some reason before, like it makes it easier for tools to scrape out all the imports from a file. But seems like a lame excuse to me now that DMD can spit out a list of imports itself. I would guess it's just a matter of not having a pressing enough need for it. But it would be nice. --bb
Jan 27 2008
next sibling parent Russell Lewis <webmaster villagersonline.com> writes:
I often add new imports for some temporary debugging code (such as 
importing std.gc so that I can call fullCollect() to debug a memory 
leak) but then forget to remove them later.

I wonder: if DMD can produce the list of imports, then is there any need 
for (mandatory) imports anymore?  Why not just let a fully-qualified 
name automatically import the right module?  An import statement, then, 
would just be a way of importing an entire module's set of symbols so 
that you didn't have to fully-qualify everything for heavily used modules.

Bill Baxter wrote:
 Leandro Lucarella wrote:
 Is there any good reason for not allowing import statements in function
 bodies or any code block? I think it would be really useful for avoid
 namespace polution, specially in unittests (it's really ugly to import
 things a module will never use except for unittesting).

Did someone already suggest using the version(UnitTest) workaround? I do remember hearing some reason before, like it makes it easier for tools to scrape out all the imports from a file. But seems like a lame excuse to me now that DMD can spit out a list of imports itself. I would guess it's just a matter of not having a pressing enough need for it. But it would be nice. --bb

Jan 27 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el 28 de enero a las 12:16 me escribiste:
 Leandro Lucarella wrote:
Is there any good reason for not allowing import statements in function
bodies or any code block? I think it would be really useful for avoid
namespace polution, specially in unittests (it's really ugly to import
things a module will never use except for unittesting).

Did someone already suggest using the version(UnitTest) workaround?

Yes, but I was looking for a design desition for making me use a workarround :)
 I do remember hearing some reason before, like it makes it easier for tools to
scrape out all the imports from a file.  But seems like a lame excuse to me now 
 that DMD can spit out a list of imports itself.  I would guess it's just a
matter of not having a pressing enough need for it.  But it would be nice.

Ok. /me pressing -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Hey you, with you ear against the wall Waiting for someone to call out Would you touch me?
Jan 28 2008
prev sibling next sibling parent Larry <lawrence.hemsley gmail.com> writes:
Leandro Lucarella Wrote:

 Is there any good reason for not allowing import statements in function
 bodies or any code block? I think it would be really useful for avoid
 namespace polution, specially in unittests (it's really ugly to import
 things a module will never use except for unittesting).
 
 -- 
 Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
 ----------------------------------------------------------------------------
 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
 ----------------------------------------------------------------------------
 Long you live and high you fly
 And smiles you'll give and tears you'll cry
 And all you touch and all you see
 Is all your life will ever be. 

Good answer. Another Pink Floyd fan!!!! Larry
Jan 28 2008
prev sibling next sibling parent reply "David Wilson" <dw botanicus.net> writes:
On 1/28/08, Leandro Lucarella <llucax gmail.com> wrote:
 Is there any good reason for not allowing import statements in function
 bodies or any code block? I think it would be really useful for avoid
 namespace polution, specially in unittests (it's really ugly to import
 things a module will never use except for unittesting).

When I started using D I thought this was pretty ugly too, but in retrospect I can't see any problem at all any more. Specifically, importing a module merely brings its symbols into view, it does *not* result in some magical linking of code from that module or anything else. In other words, I no longer see any reason why I'd *want* to import from within a unittest{} block, other than for locality and perhaps a slight increase in self descriptiveness. The namespace pollution argument is not compelling: you are going to run into symbol name conflicts when running your unit tests, regardless of the import being inside the block or not. This is the only thing I can see wrong with "pollution". The other "problem", accidentally using a function you probably desired anyway from inside real code, just saves a little typing. And since you are writing unit tests you would have probably caught the other case of using the wrong function.. :) I'd love to hear from more experienced D'ers about problems I haven't considered, but since I am yet to see any kind of name conflict in my code (4 months on), I'm not really interested in the pollution argument. It's a corner case (IMHO) not worthy of the syntax change. David. --- import std.stdio; // For unit tests. import std.foo.bar; import bar.baz.util;
 --
 Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
 ----------------------------------------------------------------------------
 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
 ----------------------------------------------------------------------------
 Long you live and high you fly
 And smiles you'll give and tears you'll cry
 And all you touch and all you see
 Is all your life will ever be.

Feb 01 2008
parent Russell Lewis <webmaster villagersonline.com> writes:
David Wilson wrote:
 When I started using D I thought this was pretty ugly too, but in
 retrospect I can't see any problem at all any more. Specifically,
 importing a module merely brings its symbols into view, it does *not*
 result in some magical linking of code from that module or anything
 else.

Magical linking, no. But it does allow you to access symbols in modules which you are going to link to anyhow but which normally would not be referenced in your code. std.stdio.writeln() is a classic example.
Feb 01 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
David Wilson, el  1 de febrero a las 12:52 me escribiste:
 On 1/28/08, Leandro Lucarella <llucax gmail.com> wrote:
 Is there any good reason for not allowing import statements in function
 bodies or any code block? I think it would be really useful for avoid
 namespace polution, specially in unittests (it's really ugly to import
 things a module will never use except for unittesting).

When I started using D I thought this was pretty ugly too, but in retrospect I can't see any problem at all any more. Specifically, importing a module merely brings its symbols into view, it does *not* result in some magical linking of code from that module or anything else.

I know, but it makes the compiler process all the extra files, which takes time. I know the compiler is prety fast so it's not that bad, but it's still not necessary to import symbols I wont use.
 In other words, I no longer see any reason why I'd *want* to
 import from within a unittest{} block, other than for locality and
 perhaps a slight increase in self descriptiveness.

And that are 2 good reasons too by thierselves.
 The namespace pollution argument is not compelling: you are going to
 run into symbol name conflicts when running your unit tests,
 regardless of the import being inside the block or not.

But you don't polute the "real" code, which makes it simpler and more readable.
 This is the
 only thing I can see wrong with "pollution". The other "problem",
 accidentally using a function you probably desired anyway from inside
 real code, just saves a little typing. And since you are writing unit
 tests you would have probably caught the other case of using the wrong
 function.. :)
 
 I'd love to hear from more experienced D'ers about problems I haven't
 considered, but since I am yet to see any kind of name conflict in my
 code (4 months on), I'm not really interested in the pollution
 argument. It's a corner case (IMHO) not worthy of the syntax change.

I agree is not a *big* problem, but I think you agree that *is* a problem. Since at first sight seems trivial to fix, I just want to know why it's not fixed. You just told me what harmless it is, I asked why it's not fixed, or if there is some issue I can't see at first sight why it can't be fixed. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- The Muppet show was banned from TV in Saudi Arabia Because one of its stars was a pig
Feb 01 2008