View mode: basic / threaded / horizontal-split · Log in · Help
October 15, 2012
Import improvement
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?
October 15, 2012
Re: Import improvement
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.
October 15, 2012
Re: Import improvement
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.
October 15, 2012
Re: Import improvement
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!
October 15, 2012
Re: Import improvement
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.
October 15, 2012
Re: Import improvement
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
October 15, 2012
Re: Import improvement
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.
October 15, 2012
Re: Import improvement
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
October 15, 2012
Re: Import improvement
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
October 15, 2012
Re: Import improvement
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
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home