digitalmars.D - Re: Flag proposal
- 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
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
Jun 10 2011
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.
Jun 10 2011
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
Jun 10 2011
"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.
Jun 10 2011