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