Re: Suggestion to implement __traits(getImports, Scope)

[captaindet via Digitalmars-d]

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

Re: Suggestion to implement __traits(getImports, Scope)

[Mason McGill via Digitalmars-d]

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?

Re: Suggestion to implement __traits(getImports, Scope)

[bearophile via Digitalmars-d]

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

Re: Suggestion to implement __traits(getImports, Scope)

[Adam D. Ruppe via Digitalmars-d]

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.

Re: Suggestion to implement __traits(getImports, Scope)

[Yuriy via Digitalmars-d]

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?

Re: Suggestion to implement __traits(getImports, Scope)

[Adam D. Ruppe via Digitalmars-d]

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)

Re: Suggestion to implement __traits(getImports, Scope)

[captaindet via Digitalmars-d]

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