Worth a look:

http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute

Andrei

On Friday, 29 August 2014 at 16:48:52 UTC, Andrei Alexandrescu wrote:
> Worth a look:
>
> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute
>
> Andrei

This is exactly the stuff I have referring to in DConf talk as "must have things that are simple by concept but very hard to implement correctly for a newcomer" :) Exactly type of helpers I'd love to add in future std.meta

On Fri, Aug 29, 2014 at 09:48:51AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> Worth a look:
> 
> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute
[...]

Wow. That's ... awesome. Kudos to Adam for the ingenuity!!! Compile-time reflection FTW!

The mixin("import "...) line was mind-blowingly ingenious, I have to say. As are the mixin(x) lines where x is an alias, to coax the compiler to recursively scan submodules. D seriously rawkz for compile-time reflection.


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen

> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute

That's what a good part of his book is about, also. A nice read, one
of my favorite chapters of the "D Cookbook".
Ideally, Adam should do a PR for Phobos to add some code-walking
ability like this.

I'm interested by any answer on one of his points: is there currently a way to find function-local imports?

There's another bug I didn't notice when writing the SO answer: the "module b.d;" didn't actually get picked up. Renaming it to "module b;" works, but not when it includes the package.

ooooh cuz it is considered "package mod" in stringof.... which has no members. Maybe if the compiler just called it "module foo.bar" instead of "package foo" we'd be in business though.

On Fri, Aug 29, 2014 at 7:12 PM, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> The mixin("import "...) line was mind-blowingly ingenious, I have to
> say.

I remember using the same 'module' trick a few years ago (that is, getting a name with __traits and testing whether it begins with "module " or not) and, like Adam, being a bit ashamed by what I just did :) While reading his book this summe, I was, like, "Oh, then this is what we all do".

Ideally, there should be a __traits(getModules) or
__traits(getImports, ...). I know, I know, "where is the PR?".

Also, this helper!(__traits) just to avoid a hole in the alias syntax is... what we all do here I suppose, but honestly the parser should accept

alias member = __traits(getMember, ID, memberName);

as valid D code.

On Fri, Aug 29, 2014 at 05:06:56PM +0000, Dicebot via Digitalmars-d wrote:
> On Friday, 29 August 2014 at 16:48:52 UTC, Andrei Alexandrescu wrote:
> >Worth a look:
> >
> >http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute
> >
> >Andrei
> 
> This is exactly the stuff I have referring to in DConf talk as "must have things that are simple by concept but very hard to implement correctly for a newcomer" :) Exactly type of helpers I'd love to add in future std.meta

A lot of Adam's stuff are in that category.

One of the things I find eminently useful in my own code is the pseudo-"slots-and-signals" design of arsd.eventloop, which contains a particularly ingenious bit of code that does *runtime* dispatching of signal types (basically structs) to handlers of the correct type (delegates receiving structs of a specific type). The code figures out which signals to send to which delegates *at runtime*. The way this is done is to use the .mangleof of the struct's type as key to an AA of arrays of handlers, suitably wrapped to allow runtime-binding of incoming struct type to delegate parameter type. I highly recommending studying how Adam's code achieves this. :-)


T

-- 
May you live all the days of your life. -- Jonathan Swift

On Friday, 29 August 2014 at 17:29:34 UTC, H. S. Teoh via Digitalmars-d wrote:
> The code figures out which signals to send to which delegates
> *at runtime*. The way this is done is to use the .mangleof of
> the struct's type as key to an AA

I think there might be an easier way to do this too: cast(size_t) typeid(T). That'd be a unique integer for each type too that could be passed through the pipe... IIRC the reason I went with the mangle hash though was to work across processes, where the TypeInfo pointer might not as reliable (my rpc.d file works more in that direction but I can't recall if I actually finished it or not).

BTW that eventloop thing uses malloc/free now whereas in the first draft it used the GC. Why? While the pointer was sitting in the kernel pipe buffer, the GC would sometimes collect it, causing random crashes. Just because the pointer hasn't left the program entirely doesn't mean the GC can still see it! I think I wrote this story in my book too in one of those little info boxes.

On Friday, 29 August 2014 at 17:17:07 UTC, Adam D. Ruppe wrote:
> There's another bug I didn't notice when writing the SO answer: the "module b.d;" didn't actually get picked up. Renaming it to "module b;" works, but not when it includes the package.
>
> ooooh cuz it is considered "package mod" in stringof.... which has no members. Maybe if the compiler just called it "module foo.bar" instead of "package foo" we'd be in business though.

Yes this is a known and unfortunate limitation with this technique :(

On Friday, 29 August 2014 at 17:29:34 UTC, H. S. Teoh via Digitalmars-d wrote:

> A lot of Adam's stuff are in that category.
(...)
> I highly recommending studying how Adam's code achieves this. :-)

It's also a bit hypnotic. I wanted to do a quick test of his simpledisplay.d module, after reading one of his recipes. I fetched his github repo and... found myself one hour later, still reading a totally different module :)