• bearophile <bearophileHUGS lycos.com> Jun 10 2011
• Adam Ruppe <destructionator gmail.com> Jun 10 2011
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jun 10 2011
• "Nick Sabalausky" <a a.a> Jun 10 2011

bearophile <bearophileHUGS lycos.com> writes:

David Nadlinger:

 At least allowing imports in unittests would be nice though – I 
 frequently find myself writing »version (unittest) {}« blocks before the 
 actual unit tests just to import some modules not needed during regular 
 builds (yeah, I suppose I'm somewhat pedantic about that).


version(unittest) was added just to solve this problem, and for me it's a good
solution. So imports in unittests is an anti-justification for the
turtle-import feature.

Bye,
bearophile

Adam Ruppe <destructionator gmail.com> writes:

Function local imports make it easier to reason about the code
which is of slight importance. The big thing I'd like though is
using it with mixins.

In my cgi.d, there's a mixin main that depends on std.string being
available inside the mixed in function.

Currently, I use a public import of std.string. Alternatively, the
other module could import it too, but that is pretty opaque.


But a scoped import would be cleaner: I could ensure it's always
available in that function without making the mixin user wonder
WTF the error messages are about and without polluting his namespace.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 6/10/11 8:44 PM, Adam Ruppe wrote:
 Function local imports make it easier to reason about the code
 which is of slight importance. The big thing I'd like though is
 using it with mixins.

 In my cgi.d, there's a mixin main that depends on std.string being
 available inside the mixed in function.

 Currently, I use a public import of std.string. Alternatively, the
 other module could import it too, but that is pretty opaque.


 But a scoped import would be cleaner: I could ensure it's always
 available in that function without making the mixin user wonder
 WTF the error messages are about and without polluting his namespace.


Yes. Local imports facilitate local reasoning.

Andrei

"Nick Sabalausky" <a a.a> writes:

"Adam Ruppe" <destructionator gmail.com> wrote in message 
news:isuhab$17hb$1 digitalmars.com...
 Function local imports make it easier to reason about the code
 which is of slight importance. The big thing I'd like though is
 using it with mixins.

 In my cgi.d, there's a mixin main that depends on std.string being
 available inside the mixed in function.

 Currently, I use a public import of std.string. Alternatively, the
 other module could import it too, but that is pretty opaque.


I have need to do that sort of thing now and then, too. What I usually do is 
include it in my module as a public renamed import, renamed with some 
special prefix, like "_myModuleName_theOriginalName". Then I use that 
super-ugly name inside the code that's intended to be mixed in. It's an ugly 
hack, but at least it's semi-hygenic and works. Scoped imports would 
probably be far better.

 But a scoped import would be cleaner: I could ensure it's always
 available in that function without making the mixin user wonder
 WTF the error messages are about and without polluting his namespace.