Hello D community,
What do you think of a new __traits(getImports, Scope), that returns a tuple of strings, which are imports made in a scope? If scope is a module, it will produce a tuple like ("std.conv", "std.traits").

Yuriy:

> What do you think of a new __traits(getImports, Scope), that returns a tuple of strings, which are imports made in a scope? If scope is a module, it will produce a tuple like ("std.conv", "std.traits").

Please explain one or more use cases.

Bye,
bearophile

You can actually get imports on module level now with __traits(allMembers). They'll be seen as members whose .stringof startsWith("module ").

But it won't work on a local scope.

Adam, that doesn't seem to work for me:
import std.typetuple;
import std.string;
import std.stdio;

template isImport(string i)
{
    static if (__traits(compiles, mixin(i).stringof) && mixin(i).stringof.startsWith("module "))
        enum isImport = true;
    else
        enum isImport = false;
}

alias GetModuleImports(string moduleName) = Filter!(isImport, __traits(allMembers, mixin(moduleName)));

unittest
{
    foreach(i; GetModuleImports!__MODULE__)
    {
        writeln("import ", i.stringof);
    }
}

This will output just:
import "object"

What did i miss here?

Hmm, weird, it shows up as "package std" now and its members aren't available.

Maybe it doesn't work to get all the imports yet :( (but i thought it did, maybe this actually changed recently, idk, a specific trait would prolly be better since then it would be well-defined)

On 2014-05-08 13:28, Yuriy wrote:
> Hello D community,
> What do you think of a new __traits(getImports, Scope), that returns a tuple of strings, which are imports made in a scope? If scope is a module, it will produce a tuple like ("std.conv", "std.traits").

by coincidence, i have use for this too. also thought __traits(allMembers, ...) would work. too bad it doesn't. is this a bug or expected behavior?

/det

On Friday, 9 May 2014 at 04:09:46 UTC, captaindet wrote:
> by coincidence, i have use for this too. also thought __traits(allMembers, ...) would work. too bad it doesn't. is this a bug or expected behavior?
>
> /det

Just out of curiosity, what's your use case?

On 2014-05-09 04:46, Mason McGill wrote:
> On Friday, 9 May 2014 at 04:09:46 UTC, captaindet wrote:
>> by coincidence, i have use for this too. also thought __traits(allMembers, ...) would work. too bad it doesn't. is this a bug or expected behavior?
>>
>> /det
>
> Just out of curiosity, what's your use case?

i create a class at compile time to ease interfacing a huge package, mostly to spare the user tons of boilerplate code. not all sub-modules are interesting. since they have to be (public) imported into the module that generates the helping class, this could switch on - in a very transparent way for the user - the generation of respective boilerplate code and exposing functionality.

obviously, i want to avoid a public import of the whole package - since only a few sub-modules will be used. currently, i have 2 different places in my helper module where functionality is switched on (for imports, and for code generation) and i don't like it.

i will experiment with mixin templates now, but i find this approach ugly and not transparent.

/det