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.

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

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

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?

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

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.
>

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

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.