www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion to implement __traits(getImports, Scope)

reply "Yuriy" <yuriy.glukhov gmail.com> writes:
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").
May 08 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
May 08 2014
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
May 08 2014
parent reply "Yuriy" <yuriy.glukhov gmail.com> writes:
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?
May 08 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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)
May 08 2014
prev sibling parent reply captaindet <2krnk gmx.net> writes:
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
May 08 2014
parent reply "Mason McGill" <mmcgill caltech.edu> writes:
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?
May 09 2014
parent captaindet <2krnk gmx.net> writes:
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
May 10 2014