www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New guideline to place import statements as locally as possible

reply "Steve Teale" <steve.teale britseyeview.com> writes:
Can someone tell me where this is written up?

Thanks
Steve
Mar 21 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 21 March 2014 at 07:24:43 UTC, Steve Teale wrote:
 Can someone tell me where this is written up?

 Thanks
 Steve
You mean generally, or in phobos? The rational in phobos is that since it is heavily templated, it makes sense to pull the imports on a "as needed" basis. If we placed all the imports needed *anywhere* in the module at the top, in *all* modules, then importing *anything* in std would import the world. for example, something as "dumb" as TypeTuple: => need std.typetuple => pulls traits => pulls typecons and algorithm => pulls array, string, uni, ascii, utf, conv => pulls everything remaining The new scheme allows massively reducing these dependencies. At least, that's the point. cross-module aliasing, and template constraints tend to make this as smooth as we'd like it. In end user code, or in non-template code, there is less rational for doing this. At that point, it only becomes a style, issue, of whether or not you want to "pollute" your namespace with imported symbols.
Mar 21 2014
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Friday, 21 March 2014 at 08:05:09 UTC, monarch_dodra wrote:
 On Friday, 21 March 2014 at 07:24:43 UTC, Steve Teale wrote:
 Can someone tell me where this is written up?

 Thanks
 Steve
You mean generally, or in phobos? The rational in phobos is that since it is heavily templated, it makes sense to pull the imports on a "as needed" basis. If we placed all the imports needed *anywhere* in the module at the top, in *all* modules, then importing *anything* in std would import the world. for example, something as "dumb" as TypeTuple: => need std.typetuple => pulls traits => pulls typecons and algorithm => pulls array, string, uni, ascii, utf, conv => pulls everything remaining The new scheme allows massively reducing these dependencies. At least, that's the point. cross-module aliasing, and template constraints tend to make this as smooth as we'd like it. In end user code, or in non-template code, there is less rational for doing this. At that point, it only becomes a style, issue, of whether or not you want to "pollute" your namespace with imported symbols.
OK, so what happens that's different when I pull in std.typetuple at the point where I need it? Does that avoid pulling in all the other stuff? How does this problem manifest itself - code bloat, or slower compilations, or what? Thanks Steve
Mar 21 2014
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 21 March 2014 at 10:03:20 UTC, Steve Teale wrote:
 OK, so what happens that's different when I pull in 
 std.typetuple at the point where I need it? Does that avoid 
 pulling in all the other stuff?
The difference is whether or not the import gets executed at all. For *you*, it doesn't make much difference where you do your import, it only impacts the people that are *importing you*. A trivial example is this: //---- module someModule; void foo(T)(T t) { import someOtherModule1; } void bar(T)(T t) { import someOtherModule2; } //---- Now imagine you need to use someModule.foo. You don't need "someOtherModule2", since that's only needed by baz. So this approach means you don't import it. someOtherModule1. //---- If the functions are not template, or in end user code, it doesn't change much where you do the imports, since they'll happen anyways. The only difference is which symbols are visible where.
 How does this problem manifest itself - code bloat, or slower 
 compilations, or what?
I can't answer that personally. I just know there was a pretty big push from the dmd guys to cleanup the phobos code. I don't know what the actual impacts are.
Mar 21 2014