October 15, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Monday, 15 October 2012 at 15:37:06 UTC, Andrei Alexandrescu wrote: > I don't think imports from a specific package have been considered. > > In my personal opinion, imports are a necessary evil and it's sort of a bummer that the most accessible place in any source file - the top lines - is occupied by the crappy legal disclaimer (which, after having talked to a lawyer, I always put at the bottom since being at the top is not a requirement), and the litany of imports that the module is using. I'd make all imports local or put them at the bottom of the file if it weren't too much of a shock to others. > > Three remarks on this particular problem. > > 1. I expect large packages to introduce a module "all.di" or "_.di" to publicly import everything in the package. That could help some use cases. It is a common practice (usually all.di) but perhaps it could help to establish an official convention. Nothing in the language, just the styleguide. (I know this has already come up and been discussed.) > 2. The import declaration accepts a list of modules, and several may be on one line. I think that's a significant positive difference from C, C++, or Go, all of which force one imported module per line. I always advocate imports from the same package in the same "import" declaration, ordered alphabetically: > > import fuji.filesystem, fuji.font, fuji.material, fuji.matrix, > fuji.primitive, fuji.render, fuji.system; > import std.algorithm, std.conv, std.random, std.string, std.xml; > ... > > That makes the existing system much more palatable. I've done this very thing for eons, and yes you are quite right! (Although my formatting is different, but I digress.) That said, I think the OP still has a valid, even quite strong point. Consider, in comparison to your sample: import fuji.( filesystem, font, material, matrix, primitive, render, system ); import std.( algorithm, conv, random, string, xml ); Certainly less visual noise. An even *better* level of improvement comes if we provide an alternate and similar syntax for selective imports, so that they no longer have to be separated. import std.( algorithm, conv, random, xml, stdio:( write, writef, writefln ), string:( munch, splitLines, xformat, xsformat ) ); As for implementation, how difficult is it for the compiler to internally expand something like this into the traditional litany? > 3. I think local imports are currently underutilized. It would be interesting to see what kind of project dynamics they enable. I can agree with this. -- Chris Nicholson-Sauls |
October 15, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | IMHO it should be IDE's job. When coding Java or C#, you select "Fix imports" and IDE automatically removes unused imports and adds new imports for undefined symbols. By the way, what about syntax like this: import std.*; would it make sense? |
October 15, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 2012-10-15, 19:13, Jacob Carlborg wrote: > Shouldn't it be possible to create a mixin that does this? > > mixin require("std", "xml", "string"); > > Something like that. But you would still need to import the "require" function. Put it in object.d, then. Still, I feel the language already has the required sugar in that one may import a list of modules. -- Simen |
October 15, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to JN | On 2012-10-15, 20:52, JN wrote: > IMHO it should be IDE's job. When coding Java or C#, you select "Fix imports" and IDE automatically removes unused imports and adds new imports for undefined symbols. > > By the way, what about syntax like this: > > import std.*; > > would it make sense? It sorta would, but creating an all.d file and importing std.all instead works just as fine. -- Simen |
October 15, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to JN Attachments:
| On 15 October 2012 21:52, JN <666total@wp.pl> wrote: > IMHO it should be IDE's job. When coding Java or C#, you select "Fix imports" and IDE automatically removes unused imports and adds new imports for undefined symbols. > Can you name an (industry standard) IDE that works well with D? By the way, what about syntax like this: > > import std.*; > > would it make sense? > In my case, I don't want to import everything. |
October 15, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On Monday, 15 October 2012 at 19:15:44 UTC, Manu wrote:
[...]
>
> In my case, I don't want to import everything.
how about something along the lines of Pythons
from X import Y, Z
where X would specifically be a package, and Y and Z would be the modules imported. This should keep things simple for both programmer and compiler alike.
|
October 15, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | On 2012-10-15 21:13, Simen Kjaeraas wrote: >> By the way, what about syntax like this: >> >> import std.*; >> >> would it make sense? > > It sorta would, but creating an all.d file and importing std.all > instead works just as fine. I would really like to have this feature instead of having to manually create these all.d files. -- /Jacob Carlborg |
October 15, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Nicholson-Sauls | On Mon, 15 Oct 2012 13:38:31 -0500, Chris Nicholson-Sauls <ibisbasenji@gmail.com> wrote:
> On Monday, 15 October 2012 at 15:37:06 UTC, Andrei Alexandrescu wrote:
>> I don't think imports from a specific package have been considered.
>>
>> In my personal opinion, imports are a necessary evil and it's sort of a bummer that the most accessible place in any source file - the top lines - is occupied by the crappy legal disclaimer (which, after having talked to a lawyer, I always put at the bottom since being at the top is not a requirement), and the litany of imports that the module is using. I'd make all imports local or put them at the bottom of the file if it weren't too much of a shock to others.
>>
>> Three remarks on this particular problem.
>>
>> 1. I expect large packages to introduce a module "all.di" or "_.di" to publicly import everything in the package. That could help some use cases.
>
> It is a common practice (usually all.di) but perhaps it could help to establish an official convention. Nothing in the language, just the styleguide. (I know this has already come up and been discussed.)
I like what vibe.d did by having an import all file named d.d
Therefore you can:
import vibe.d;
It's nice, it's clean, and I've blatantly stolen it for a few of my own projects.
|
October 16, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to 1100110 | On Monday, 15 October 2012 at 23:43:53 UTC, 1100110 wrote:
> I like what vibe.d did by having an import all file named d.d
>
> Therefore you can:
> import vibe.d;
>
> It's nice, it's clean, and I've blatantly stolen it for a few of my own projects.
It's cute, but I think it is terribly misleading. I wouldn't recommend that to anyone.
|
October 16, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On Mon, 15 Oct 2012 19:10:02 -0500, Peter Alexander <peter.alexander.au@gmail.com> wrote: > On Monday, 15 October 2012 at 23:43:53 UTC, 1100110 wrote: >> I like what vibe.d did by having an import all file named d.d >> >> Therefore you can: >> import vibe.d; >> >> It's nice, it's clean, and I've blatantly stolen it for a few of my own projects. > > It's cute, but I think it is terribly misleading. I wouldn't recommend that to anyone. How is it misleading? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
Copyright © 1999-2021 by the D Language Foundation