digitalmars.D - Why import statements are not allowed in function bodies (or any block of code)?
- Leandro Lucarella (13/13) Jan 27 2008 Is there any good reason for not allowing import statements in function
- Bill Baxter (8/13) Jan 27 2008 Did someone already suggest using the version(UnitTest) workaround?
- Russell Lewis (9/25) Jan 27 2008 I often add new imports for some temporary debugging code (such as
- Leandro Lucarella (13/22) Jan 28 2008 Yes, but I was looking for a design desition for making me use a
- Larry (4/18) Jan 28 2008 Good answer.
- David Wilson (26/39) Feb 01 2008 When I started using D I thought this was pretty ugly too, but in
- Leandro Lucarella (19/47) Feb 01 2008 I know, but it makes the compiler process all the extra files, which tak...
- Russell Lewis (4/9) Feb 01 2008 Magical linking, no. But it does allow you to access symbols in modules...
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
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
Russell Lewis <webmaster villagersonline.com> 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
Bill Baxter, el 28 de enero a las 12:16 me escribiste:Leandro Lucarella wrote:Yes, but I was looking for a design desition for making me use a workarround :)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.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
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
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
David Wilson, el 1 de febrero a las 12:52 me escribiste:On 1/28/08, Leandro Lucarella <llucax gmail.com> wrote: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.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.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
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