www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Import improvement

reply Manu <turkeyman gmail.com> writes:
--047d7b6d9340b83d3104cc18630a
Content-Type: text/plain; charset=UTF-8

So I'm getting sick of this in my files:

module stache.states.ingamestate;

import fuji.filesystem;
import fuji.render;
import fuji.matrix;
import fuji.material;
import fuji.primitive;
import fuji.system;
import fuji.font;

import std.xml;
import std.string;
import std.conv;
import std.random;
import std.algorithm;

import stache.battlecamera;

import stache.i.statemachine;
import stache.game;

import stache.util.eventtypes;

import stache.i.entity;
import stache.entity.combatant;
import stache.entity.paimei;

import stache.thinkers.localplayer;
import stache.thinkers.nullthinker;

import stache.i.collider;

import stache.sound.soundset;
import stache.sound.music;


This is obviously silly.
I know this could be improved with some care, more liberal public imports
(dangerous, you risk ending up with EVERYTHING as public import if it
sticks as a standard convention), better maintained dependencies... but
it's not realistic in a production environment. That sort
of maintenance just never happens.

I suggest expanding the selective import mechanism to extend to modules,
not just functions within a module, eg:

module stache.states.ingamestate;

import fuji: filesystem, render, matrix, material, primitive, system, font;
import std: xml, string, conv, random, algorithm;
import stache: game, battlecamera;
import stache.i: statemachine, entity, collider;
import stache.entity: combatant, paimei;
import stache.thinkers: localplayer, nullthinker;
import stache.sound: soundset, music;
import stache.util.eventtypes;

This is much better! Saved ~25 lines of import rubbish, and it also
enforces logical grouping; individual import statements tends to lead to
related submodules being distanced from eachother, this way, they appear on
the same line.

Surely this has been considered before. Any reasons it's not supported?

--047d7b6d9340b83d3104cc18630a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So I&#39;m getting sick of this in my files:<div><br></div><div><div>module=
 stache.states.ingamestate;</div><div><br></div><div>import fuji.filesystem=
;</div><div>import fuji.render;</div><div>import fuji.matrix;</div><div>
import fuji.material;</div><div>import fuji.primitive;</div><div>import fuj=
i.system;</div><div>import fuji.font;</div><div><br></div><div>import std.x=
ml;</div><div>import std.string;</div><div>import std.conv;</div><div>impor=
t std.random;</div>
<div>import std.algorithm;</div><div><br></div><div>import stache.battlecam=
era;</div><div><br></div><div>import stache.i.statemachine;</div><div>impor=
t stache.game;</div><div><br></div><div>import stache.util.eventtypes;</div=

combatant;</div><div>import stache.entity.paimei;</div><div><br></div><div>= import stache.thinkers.localplayer;</div><div>import stache.thinkers.nullth= inker;</div> <div><br></div><div>import stache.i.collider;</div><div><br></div><div>impo= rt stache.sound.soundset;</div><div>import stache.sound.music;</div></div><= div><br></div><div><br></div><div>This is obviously silly.</div><div>I know= this could be improved with some care, more liberal public imports (danger= ous, you risk ending up with EVERYTHING as public import if it sticks as a = standard convention), better maintained dependencies... but it&#39;s not re= alistic in a production environment. That sort of=C2=A0maintenance=C2=A0jus= t never happens.</div> <div><br></div><div>I suggest expanding the selective import mechanism to e= xtend to modules, not just functions within a module, eg:</div><div><br></d= iv><div><div>module stache.states.ingamestate;</div><div><br></div><div> import fuji: filesystem,=C2=A0render,=C2=A0matrix,=C2=A0material,=C2=A0prim= itive,=C2=A0system,=C2=A0font;</div><div>import std: xml,=C2=A0string,=C2= =A0conv,=C2=A0random,=C2=A0algorithm;</div><div>import stache: game, battle= camera;</div><div><div>import stache.i: statemachine,=C2=A0entity,=C2=A0col= lider;</div> </div><div>import stache.entity: combatant,=C2=A0paimei;</div><div>import s= tache.thinkers: localplayer,=C2=A0nullthinker;</div><div>import stache.soun= d: soundset,=C2=A0music;</div></div><div><div>import stache.util.eventtypes= ;</div></div> <div><br></div><div>This is much better! Saved ~25 lines of import rubbish,= and it also enforces logical grouping; individual import statements tends = to lead to related submodules being distanced from eachother, this way, the= y appear on the same line.</div> <div><br></div><div>Surely this has been considered before. Any reasons it&= #39;s not supported?</div> --047d7b6d9340b83d3104cc18630a--
Oct 15 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 15/10/2012 14:43, Manu a écrit :
 So I'm getting sick of this in my files:

 module stache.states.ingamestate;

 import fuji.filesystem;
 import fuji.render;
 import fuji.matrix;
 import fuji.material;
 import fuji.primitive;
 import fuji.system;
 import fuji.font;

 import std.xml;
 import std.string;
 import std.conv;
 import std.random;
 import std.algorithm;

 import stache.battlecamera;

 import stache.i.statemachine;
 import stache.game;

 import stache.util.eventtypes;

 import stache.i.entity;
 import stache.entity.combatant;
 import stache.entity.paimei;

 import stache.thinkers.localplayer;
 import stache.thinkers.nullthinker;

 import stache.i.collider;

 import stache.sound.soundset;
 import stache.sound.music;


 This is obviously silly.
 I know this could be improved with some care, more liberal public
 imports (dangerous, you risk ending up with EVERYTHING as public import
 if it sticks as a standard convention), better maintained
 dependencies... but it's not realistic in a production environment. That
 sort of maintenance just never happens.

 I suggest expanding the selective import mechanism to extend to modules,
 not just functions within a module, eg:

 module stache.states.ingamestate;

 import fuji: filesystem, render, matrix, material, primitive, system, font;
 import std: xml, string, conv, random, algorithm;
 import stache: game, battlecamera;
 import stache.i: statemachine, entity, collider;
 import stache.entity: combatant, paimei;
 import stache.thinkers: localplayer, nullthinker;
 import stache.sound: soundset, music;
 import stache.util.eventtypes;

 This is much better! Saved ~25 lines of import rubbish, and it also
 enforces logical grouping; individual import statements tends to lead to
 related submodules being distanced from eachother, this way, they appear
 on the same line.

 Surely this has been considered before. Any reasons it's not supported?

It make sense.
Oct 15 2012
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:
 Surely this has been considered before. Any reasons it's not 
 supported?

Yes, it has been considered before. There is an enhancement from ages ago in bugzilla. http://d.puremagic.com/issues/show_bug.cgi?id=3603 The syntax you proposed doesn't work, because it conflicts with selective imports: ===[std.d]=== module std; void stdio() {} ===[test.d]=== import std : stdio; Does that import the stdio function from module std, or the module std.stdio? You could use something like this: import std.(stdio, xml, algorithm); Of course, there's many variations (square brackets, curly braces, no dot, no commas...) but it's all bikeshedding.
Oct 15 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 15/10/2012 15:02, Peter Alexander a écrit :
 On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:
 Surely this has been considered before. Any reasons it's not supported?

Yes, it has been considered before. There is an enhancement from ages ago in bugzilla. http://d.puremagic.com/issues/show_bug.cgi?id=3603 The syntax you proposed doesn't work, because it conflicts with selective imports: ===[std.d]=== module std; void stdio() {} ===[test.d]=== import std : stdio; Does that import the stdio function from module std, or the module std.stdio? You could use something like this: import std.(stdio, xml, algorithm); Of course, there's many variations (square brackets, curly braces, no dot, no commas...) but it's all bikeshedding.

I don't think import should make the difference between packages/modules and module content. The example you take is only ambiguous if std is both a package and a module which isn't allowed anyway now. It is a point on which people are willing to advance already (Andrei have made a proposal about it). I'm against introducing more new syntax to import. import is already a complex beast.
Oct 15 2012
prev sibling parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 15/10/2012 14:02, Peter Alexander wrote:
 You could use something like this:

 import std.(stdio, xml, algorithm);

 Of course, there's many variations (square brackets, curly braces, no
 dot, no commas...) but it's all bikeshedding.

Personally I like: import package std : stdio, xml, algorithm; compare with: import std.algorithm : sort, swap; This has nice symmetry and is unambiguous.
Oct 18 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf303b42f766fac704cc1927de
Content-Type: text/plain; charset=UTF-8

On 15 October 2012 16:02, Peter Alexander <peter.alexander.au gmail.com>wrote:

 On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:

 Surely this has been considered before. Any reasons it's not supported?

Yes, it has been considered before. There is an enhancement from ages ago in bugzilla. http://d.puremagic.com/issues/**show_bug.cgi?id=3603<http://d.puremagic.com/issues/show_bug.cgi?id=3603> The syntax you proposed doesn't work, because it conflicts with selective imports: ===[std.d]=== module std; void stdio() {} ===[test.d]=== import std : stdio; Does that import the stdio function from module std, or the module std.stdio? You could use something like this: import std.(stdio, xml, algorithm); Of course, there's many variations (square brackets, curly braces, no dot, no commas...) but it's all bikeshedding.

Awesome. Well, just throwing it out there... any mechanism by which this is possible will suit me! --20cf303b42f766fac704cc1927de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 October 2012 16:02, Peter Alexander <span dir=3D"ltr">&lt;<a href=3D"= mailto:peter.alexander.au gmail.com" target=3D"_blank">peter.alexander.au g= mail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> <div class=3D"im">On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:<b= r> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Surely this has been considered before. Any reasons it&#39;s not supported?= <br> </blockquote> <br></div> Yes, it has been considered before. There is an enhancement from ages ago i= n bugzilla.<br> <br> <a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D3603" target=3D"= _blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=3D3603</a><br> <br> The syntax you proposed doesn&#39;t work, because it conflicts with selecti= ve imports:<br> <br> =3D=3D=3D[std.d]=3D=3D=3D<br> module std;<br> void stdio() {}<br> <br> =3D=3D=3D[test.d]=3D=3D=3D<br> import std : stdio;<br> <br> Does that import the stdio function from module std, or the module std.stdi= o?<br> <br> You could use something like this:<br> <br> import std.(stdio, xml, algorithm);<br> <br> Of course, there&#39;s many variations (square brackets, curly braces, no d= ot, no commas...) but it&#39;s all bikeshedding.<br> </blockquote></div><br><div>Awesome. Well, just throwing it out there... an= y mechanism by which this is possible will suit me!</div> --20cf303b42f766fac704cc1927de--
Oct 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
deadalnix:

 I don't think import should make the difference between 
 packages/modules and module content.

This is acceptable only if then it imports the module names only. It means that later you must write "stdio.writeln()".
 I'm against introducing more new syntax to import. import is 
 already a complex beast.

The suggested syntax "import std.(stdio, xml, algorithm);" is probably sub-optimal, and maybe better solutions exist. But in most cases more syntax is way better than foggy/messy semantics. Bye, bearophile
Oct 15 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 15 October 2012 at 13:46:43 UTC, deadalnix wrote:
 I don't think import should make the difference between 
 packages/modules and module content.

 The example you take is only ambiguous if std is both a package 
 and a module which isn't allowed anyway now. It is a point on 
 which people are willing to advance already (Andrei have made a 
 proposal about it).

My example with module std works as of DMD 2.060, and I can't see anything in the spec that says it is disallowed, or are you saying that it has been agreed that it will be disallowed in the future?
 I'm against introducing more new syntax to import. import is 
 already a complex beast.

I agree, but I also don't like the idea of using the same syntax to mean two different things. import foo : bar, baz; Is this selectively importing symbols or is it importing two modules? This is mildly confusing for the programmer, and complicates parsing.
Oct 15 2012
prev sibling next sibling parent "Daniel =?UTF-8?B?S296w6FrIg==?= <kozzi11 gmail.com> writes:
On Monday, 15 October 2012 at 14:20:48 UTC, Peter Alexander wrote:
 On Monday, 15 October 2012 at 13:46:43 UTC, deadalnix wrote:
 I don't think import should make the difference between 
 packages/modules and module content.

 The example you take is only ambiguous if std is both a 
 package and a module which isn't allowed anyway now. It is a 
 point on which people are willing to advance already (Andrei 
 have made a proposal about it).

My example with module std works as of DMD 2.060, and I can't see anything in the spec that says it is disallowed, or are you saying that it has been agreed that it will be disallowed in the future?
 I'm against introducing more new syntax to import. import is 
 already a complex beast.

I agree, but I also don't like the idea of using the same syntax to mean two different things. import foo : bar, baz; Is this selectively importing symbols or is it importing two modules? This is mildly confusing for the programmer, and complicates parsing.

And what about import foo : bar, .baz; where .baz is module
Oct 15 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/15/12 8:43 AM, Manu wrote:
 So I'm getting sick of this in my files:

 This is obviously silly.

Agreed.
 I know this could be improved with some care, more liberal public
 imports (dangerous, you risk ending up with EVERYTHING as public import
 if it sticks as a standard convention), better maintained
 dependencies... but it's not realistic in a production environment. That
 sort of maintenance just never happens.

 I suggest expanding the selective import mechanism to extend to modules,
 not just functions within a module, eg:

 module stache.states.ingamestate;

 import fuji: filesystem, render, matrix, material, primitive, system, font;
 import std: xml, string, conv, random, algorithm;
 import stache: game, battlecamera;
 import stache.i: statemachine, entity, collider;
 import stache.entity: combatant, paimei;
 import stache.thinkers: localplayer, nullthinker;
 import stache.sound: soundset, music;
 import stache.util.eventtypes;

 This is much better! Saved ~25 lines of import rubbish, and it also
 enforces logical grouping; individual import statements tends to lead to
 related submodules being distanced from eachother, this way, they appear
 on the same line.

 Surely this has been considered before. Any reasons it's not supported?

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. 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. 3. I think local imports are currently underutilized. It would be interesting to see what kind of project dynamics they enable. Andrei
Oct 15 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-16 02:10, Peter Alexander wrote:

 It's cute, but I think it is terribly misleading. I wouldn't recommend
 that to anyone.

I agree. I'm using foo.bar._, that's the same used by Scala. -- /Jacob Carlborg
Oct 15 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/12 2:49 AM, Jacob Carlborg wrote:
 On 2012-10-16 02:10, Peter Alexander wrote:

 It's cute, but I think it is terribly misleading. I wouldn't recommend
 that to anyone.

I agree. I'm using foo.bar._, that's the same used by Scala.

Sounds good. Arbitrary + precedent > arbitrary. Andrei
Oct 17 2012
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 10/16/2012 2:10 AM, schrieb Peter Alexander:
 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.

I agree, in vibe.d it's just a little pun on the name, but in general it could of course be mistaken as a file name. I've used pack.pack instead of pack.all or pack._ in the past, but somehow all of them are kind of ugly without being able to just say 'pack', as in the DIP.
Oct 16 2012
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
 
 O_O .. That might be one of the worst things I've ever seen!
 It doesn't even make sense. Is there actually a vibe.d file? And why try
 to make the import statement look like a source filename?

Strong words aside, let me tell you that the "vibe.d" import is just a small convenience for quick projects, so that you don't have to write yuor own main() function - something that in general appeals to quite a few people when using web frameworks in dynamic languages. In this context it was just a funny idea to name it like this (named after the project, not to make it look like a file, of course) and make it a kind of unique trait. However, this is by no means a pattern. The module that imports everything is "vibe.vibe".
Oct 16 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 10/16/2012 1:53 PM, schrieb Manu:
 
 What's wrong with the reasonably established '_' module though? Trying
 to make it appear like a source filename is a deception. That may
 confuse the programmer.
 (...)

Again, it has *not* the same meaning as a _.d module. It's just a single, very special, module. I totally agree with the possible confusion in general. But speaking of '_' (and I have to admit that I didn't look at that many projects) - I've never seen that in the wild. And (IMO) "import something._" also looks quite awkward and non-self-explanatory, much more than either "something.all", "something.*" or "something.something". Making it just into "import somthing;" with some compiler support would of course change the game. Leaving all that aside, in larger projects I always just import single modules and rarely use public imports, only when there are compelling reasons. So I would definitely welcome something along the lines of what you proposed.
Oct 16 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-16 14:36, Sönke Ludwig wrote:

 But speaking of '_' (and I have to admit that I didn't look at that many
 projects) - I've never seen that in the wild. And (IMO) "import
 something._" also looks quite awkward and non-self-explanatory, much
 more than either "something.all", "something.*" or
 "something.something". Making it just into "import somthing;" with some
 compiler support would of course change the game.

"import something;", how would you know if it's a module or a package? I really would like to be able to use "import something.*" but the compiler doesn't support it, so .all/._ is the best we can do for now. -- /Jacob Carlborg
Oct 16 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 10/16/2012 3:11 PM, schrieb Jacob Carlborg:
 On 2012-10-16 14:36, Sönke Ludwig wrote:
 
 But speaking of '_' (and I have to admit that I didn't look at that many
 projects) - I've never seen that in the wild. And (IMO) "import
 something._" also looks quite awkward and non-self-explanatory, much
 more than either "something.all", "something.*" or
 "something.something". Making it just into "import somthing;" with some
 compiler support would of course change the game.

"import something;", how would you know if it's a module or a package? I really would like to be able to use "import something.*" but the compiler doesn't support it, so .all/._ is the best we can do for now.

The compiler has to walk the directory structure anyway. If it stops at a directory, it looks for _.d/package.d/... and uses that. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 It would definitely be good to have a decistion if the compiler will support it at some point to not start naming all those modules all.d only to dicover later that the compiler wants to have _.d.
Oct 16 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-16 16:14, Sönke Ludwig wrote:

 The compiler has to walk the directory structure anyway. If it stops at
 a directory, it looks for _.d/package.d/... and uses that.

I was more thinking of the developer reading the code. -- /Jacob Carlborg
Oct 16 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 10/16/2012 6:55 PM, schrieb Jacob Carlborg:
 On 2012-10-16 16:14, Sönke Ludwig wrote:
 
 The compiler has to walk the directory structure anyway. If it stops at
 a directory, it looks for _.d/package.d/... and uses that.

I was more thinking of the developer reading the code.

Ah OK, sorry. There is no direct way of course. But assuming that it semantically makes sense to import a package and because it's necessary to look at some kind of documentation before importing anything anyway, I guess that could be a tolerable shortcoming.
Oct 16 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-16 20:39, Sönke Ludwig wrote:

 Ah OK, sorry. There is no direct way of course. But assuming that it
 semantically makes sense to import a package and because it's necessary
 to look at some kind of documentation before importing anything anyway,
 I guess that could be a tolerable shortcoming.

Yeah, I would still prefer "import foo.bar.*" though. -- /Jacob Carlborg
Oct 16 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-19 09:22, Marco Leise wrote:

 Just an observation...

 import fuji: filesystem, render, matrix, material, primitive, system, font;
 import std: xml, string, conv, random, algorithm;

 ...is very easy on the eyes. It gives you that natural "in
 package std, there are the modules xml, string, ..."
 representation without repeatedly stating "fuji." or "std.".

I think both of these could be useful. -- /Jacob Carlborg
Oct 19 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/15/12 9:30 PM, 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.

O_O .. That might be one of the worst things I've ever seen! It doesn't even make sense. Is there actually a vibe.d file? And why try to make the import statement look like a source filename?

There is a source/vibe/d.d file. The reason it is there is because vibe.d includes it's own main(), There is a source/vibe/vibe.d file, but that is there for you to roll your own main(). Shrug. "import file.d;" <- actual name is file.d doesn't work, and it isn't designed to work like that. So unless you know nothing about how the import system works, it's not really a problem. And I would assume that it was done since the name of the project is "vibe.d". If this is the worst thing that you've seen, then I don't think you've seen golang.. Or javascript's underscore library... "_.each([1, 2, 3], function(num){ alert(num); }); => alerts each number in turn... _.each({one : 1, two : 2, three : 3}, function(num, key){ alert(num); }); => alerts each number in turn..." That might be one of the worst, most confusing things that I've seen.

Wondering what happens if one has a file called something.d.d and imports it as something.d. Andrei
Oct 17 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-15 14:43, Manu wrote:

 This is obviously silly.
 I know this could be improved with some care, more liberal public
 imports (dangerous, you risk ending up with EVERYTHING as public import
 if it sticks as a standard convention), better maintained
 dependencies... but it's not realistic in a production environment. That
 sort of maintenance just never happens.

 I suggest expanding the selective import mechanism to extend to modules,
 not just functions within a module, eg:

 module stache.states.ingamestate;

 import fuji: filesystem, render, matrix, material, primitive, system, font;
 import std: xml, string, conv, random, algorithm;
 import stache: game, battlecamera;
 import stache.i: statemachine, entity, collider;
 import stache.entity: combatant, paimei;
 import stache.thinkers: localplayer, nullthinker;
 import stache.sound: soundset, music;
 import stache.util.eventtypes;

 This is much better! Saved ~25 lines of import rubbish, and it also
 enforces logical grouping; individual import statements tends to lead to
 related submodules being distanced from eachother, this way, they appear
 on the same line.

 Surely this has been considered before. Any reasons it's not supported?

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. -- /Jacob Carlborg
Oct 15 2012
prev sibling next sibling parent "Chris Nicholson-Sauls" <ibisbasenji gmail.com> writes:
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
Oct 15 2012
prev sibling next sibling parent reply "JN" <666total wp.pl> writes:
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?
Oct 15 2012
parent Jacob Carlborg <doob me.com> writes:
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
Oct 15 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Oct 15 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Oct 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf307811d09a12e204cc1ddc64
Content-Type: text/plain; charset=UTF-8

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. --20cf307811d09a12e204cc1ddc64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 October 2012 21:52, JN <span dir=3D"ltr">&lt;<a href=3D"mailto:666tot= al wp.pl" target=3D"_blank">666total wp.pl</a>&gt;</span> wrote:<br><div cl= ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> IMHO it should be IDE&#39;s job. When coding Java or C#, you select &quot;F= ix imports&quot; and IDE automatically removes unused imports and adds new = imports for undefined symbols.<br></blockquote><div><br></div><div>Can you = name an (industry standard) IDE that works well with D?</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> By the way, what about syntax like this:<br> <br> import std.*;<br> <br> would it make sense?<br> </blockquote></div><br><div>In my case, I don&#39;t want to import everythi= ng.</div> --20cf307811d09a12e204cc1ddc64--
Oct 15 2012
prev sibling next sibling parent "Matt" <webwraith fastmail.fm> writes:
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.
Oct 15 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
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.
Oct 15 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Oct 15 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
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/
Oct 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec5014c7122de5904cc22f32a
Content-Type: text/plain; charset=UTF-8

On 16 October 2012 02:39, 1100110 <0b1100110 gmail.com> wrote:

 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.

O_O .. That might be one of the worst things I've ever seen! It doesn't even make sense. Is there actually a vibe.d file? And why try to make the import statement look like a source filename? --bcaec5014c7122de5904cc22f32a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 October 2012 02:39, 1100110 <span dir=3D"ltr">&lt;<a href=3D"mailto:0= b1100110 gmail.com" target=3D"_blank">0b1100110 gmail.com</a>&gt;</span> wr= ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Mon, 15 Oct 2012 13:38:31 -0500, Chris Nicholson-Sauls= &lt;<a href=3D"mailto:ibisbasenji gmail.com" target=3D"_blank">ibisbasenji= gmail.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Monday, 15 October 2012 at 15:37:06 UTC, Andrei Alexandrescu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I don&#39;t think imports from a specific package have been considered.<br> <br> In my personal opinion, imports are a necessary evil and it&#39;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 requir= ement), and the litany of imports that the module is using. I&#39;d make al= l imports local or put them at the bottom of the file if it weren&#39;t too= much of a shock to others.<br> <br> Three remarks on this particular problem.<br> <br> 1. I expect large packages to introduce a module &quot;all.di&quot; or &quo= t;_.di&quot; to publicly import everything in the package. That could help = some use cases.<br> </blockquote> <br> It is a common practice (usually all.di) but perhaps it could help to estab= lish an official convention. =C2=A0Nothing in the language, just the styleg= uide. =C2=A0(I know this has already come up and been discussed.)<br> </blockquote> <br></div> I like what vibe.d did by having an import all file named d.d<br> <br> Therefore you can:<br> import vibe.d;<br> <br> It&#39;s nice, it&#39;s clean, and I&#39;ve blatantly stolen it for a few o= f my own projects.<br> </blockquote></div><br><div>O_O .. That might be one of the worst things I&= #39;ve ever seen!</div><div>It doesn&#39;t even make sense. Is there actual= ly a vibe.d file? And why try to make the import statement look like a sour= ce filename?</div> --bcaec5014c7122de5904cc22f32a--
Oct 15 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
 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.

O_O .. That might be one of the worst things I've ever seen! It doesn't even make sense. Is there actually a vibe.d file? And why try to make the import statement look like a source filename?

There is a source/vibe/d.d file. The reason it is there is because vibe.d includes it's own main(), There is a source/vibe/vibe.d file, but that is there for you to roll your own main(). Shrug. "import file.d;" <- actual name is file.d doesn't work, and it isn't designed to work like that. So unless you know nothing about how the import system works, it's not really a problem. And I would assume that it was done since the name of the project is "vibe.d". If this is the worst thing that you've seen, then I don't think you've seen golang.. Or javascript's underscore library... "_.each([1, 2, 3], function(num){ alert(num); }); => alerts each number in turn... _.each({one : 1, two : 2, three : 3}, function(num, key){ alert(num); }); => alerts each number in turn..." That might be one of the worst, most confusing things that I've seen. -- Shut up, Opera
Oct 15 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
I like the idea of being able to either import a module, or 
package, with being able to choose what you want to import from 
it.

Something like
import std.stdio : writeln; (already exists)
import std : stdio, algorithm;
or just 'import std', though for something like std that would of 
course not be recommended. For smaller packages, such as 
std.datetime though, it would be useful.
Oct 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51d25d46c700b04cc2bced6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 16 October 2012 11:22, S=C3=B6nke Ludwig <sludwig outerproduct.org> wrot=
e:

 O_O .. That might be one of the worst things I've ever seen!
 It doesn't even make sense. Is there actually a vibe.d file? And why tr=


 to make the import statement look like a source filename?

Strong words aside, let me tell you that the "vibe.d" import is just a small convenience for quick projects, so that you don't have to write yuor own main() function - something that in general appeals to quite a few people when using web frameworks in dynamic languages. In this context it was just a funny idea to name it like this (named after the project, not to make it look like a file, of course) and make it a kind of unique trait. However, this is by no means a pattern. The module that imports everything is "vibe.vibe".

What's wrong with the reasonably established '_' module though? Trying to make it appear like a source filename is a deception. That may confuse the programmer. That said, I didn't realise the project incorporated '.d' in the project name. I was under the impression it was being carried to other projects too that may not share the same naming pun. --bcaec51d25d46c700b04cc2bced6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 October 2012 11:22, S=C3=B6nke Ludwig <span dir=3D"ltr">&lt;<a href= =3D"mailto:sludwig outerproduct.org" target=3D"_blank">sludwig outerproduct= .org</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div class=3D"im">&gt;<br> &gt; O_O .. That might be one of the worst things I&#39;ve ever seen!<br> &gt; It doesn&#39;t even make sense. Is there actually a vibe.d file? And w= hy try<br> &gt; to make the import statement look like a source filename?<br> <br> </div>Strong words aside, let me tell you that the &quot;vibe.d&quot; impor= t is just a<br> small convenience for quick projects, so that you don&#39;t have to write<b= r> yuor own main() function - something that in general appeals to quite a<br> few people when using web frameworks in dynamic languages.<br> <br> In this context it was just a funny idea to name it like this (named<br> after the project, not to make it look like a file, of course) and make<br> it a kind of unique trait. However, this is by no means a pattern. The<br> module that imports everything is &quot;vibe.vibe&quot;.<br> </blockquote></div><br><div>What&#39;s wrong with the reasonably establishe= d &#39;_&#39; module though? Trying to make it appear like a source filenam= e is a deception. That may confuse the programmer.</div><div>That said, I d= idn&#39;t realise the project incorporated &#39;.d&#39; in the project name= . I was under the impression it was being carried to other projects too tha= t may not share the same naming pun.</div> --bcaec51d25d46c700b04cc2bced6--
Oct 16 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 15, 2012 11:37:06 Andrei Alexandrescu wrote:
 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 would be fantastic if we could get something like DIP15/16 implemented which made it possible to do import my.pkg; instead of import my.pkg.all; or import my.pkg._; or whatever folks have come up with. And everything's there already except for making it so that when my.pkg is a package, importing my.pkg then imports a specially-named package inside of my.pkg with whatever public imports you want to have when importing the entire package. I started looking into implementing it a while back but got sidetracked before I could get very far. - Jonathan M Davis
Oct 16 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Wednesday, 17 October 2012 at 15:16:12 UTC, Andrei 
Alexandrescu wrote:
 On 10/16/12 2:49 AM, Jacob Carlborg wrote:
 On 2012-10-16 02:10, Peter Alexander wrote:

 It's cute, but I think it is terribly misleading. I wouldn't 
 recommend
 that to anyone.

I agree. I'm using foo.bar._, that's the same used by Scala.

Sounds good. Arbitrary + precedent > arbitrary. Andrei

Let's be accurate here: Meaningful >>> Arbitrary + precedent > arbitrary. If I want to truly import an _entire_ package than both: import package.all; import package.*; make sense/ meaningful. If I want to have a special file that includes specific public imports for the package's public API than it should be called appropriately. e.g: import package.api; I've seen such usage of an "api" package in Google's Android platform for instance.
Oct 17 2012
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 17 Oct 2012 08:36:11 +0200
schrieb Jacob Carlborg <doob me.com>:

 On 2012-10-16 20:39, S=C3=B6nke Ludwig wrote:
=20
 Ah OK, sorry. There is no direct way of course. But assuming that it
 semantically makes sense to import a package and because it's necessary
 to look at some kind of documentation before importing anything anyway,
 I guess that could be a tolerable shortcoming.

Yeah, I would still prefer "import foo.bar.*" though.

Just an observation... import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; ...is very easy on the eyes. It gives you that natural "in package std, there are the modules xml, string, ..." representation without repeatedly stating "fuji." or "std.". --=20 Marco
Oct 19 2012