www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Import improvement

reply Manu <turkeyman gmail.com> writes:
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?
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 Manu <turkeyman gmail.com> writes:
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!
Oct 15 2012
prev sibling next sibling parent reply 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
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 parent reply "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
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 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 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:


[snip litany of imports]

 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 "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
parent reply 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
next sibling parent reply "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
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 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 reply 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
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 =?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 parent reply Manu <turkeyman gmail.com> writes:
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?
Oct 15 2012
next sibling parent reply 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
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 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 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 Manu <turkeyman gmail.com> writes:
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=




y

 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.
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 reply 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.


=20
 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
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 "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 reply 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
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 parent reply "JN" <666total wp.pl> writes:

"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
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-10-15, 20:52, JN wrote:



 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
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 parent reply Manu <turkeyman gmail.com> writes:
On 15 October 2012 21:52, JN <666total wp.pl> wrote:



 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.
Oct 15 2012
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