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.
