Jump to page: 1 24  
Page
Thread overview
Import improvement
Oct 15, 2012
Manu
Oct 15, 2012
deadalnix
Oct 15, 2012
Peter Alexander
Oct 15, 2012
Manu
Oct 15, 2012
deadalnix
Oct 15, 2012
bearophile
Oct 15, 2012
Peter Alexander
Oct 15, 2012
Daniel Kozák
Oct 18, 2012
Nick Treleaven
Oct 15, 2012
1100110
Oct 16, 2012
Peter Alexander
Oct 16, 2012
1100110
Oct 16, 2012
Jacob Carlborg
Oct 17, 2012
foobar
Oct 16, 2012
Sönke Ludwig
Oct 16, 2012
Manu
Oct 16, 2012
1100110
Oct 16, 2012
Kapps
Oct 16, 2012
Sönke Ludwig
Oct 16, 2012
Manu
Oct 16, 2012
Sönke Ludwig
Oct 16, 2012
Jacob Carlborg
Oct 16, 2012
Sönke Ludwig
Oct 16, 2012
Jacob Carlborg
Oct 16, 2012
Sönke Ludwig
Oct 17, 2012
Jacob Carlborg
Oct 19, 2012
Marco Leise
Oct 19, 2012
Jacob Carlborg
Oct 16, 2012
Jonathan M Davis
Oct 15, 2012
Jacob Carlborg
Oct 15, 2012
Simen Kjaeraas
Oct 15, 2012
JN
Oct 15, 2012
Simen Kjaeraas
Oct 15, 2012
Jacob Carlborg
Oct 15, 2012
Manu
Oct 15, 2012
Matt
October 15, 2012
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
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
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
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
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
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
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
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
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
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