Import improvement

[Jacob Carlborg]

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