Decorator / attribute functions framework

[mihails-strasuns]

This is generic part of a feature we have been discussing few days ago. Probably a bit overly generic but that D metaprogramming is like drugs - very hard to stop once addiction is up and running :(

Unittest examples should provide a clear picture how this is going to be used for enhancing the REST module (this is work-in-progress currently).

Slightly off-topic; do you think something like that may fit into Phobos after some field testing or it feels too weird for stdlib?

/// example
unittest
{
    struct Context
    {   
        int increment;
        string token;
        bool updated = false;
    }   

    static int genID(Context* context)
    {   
        static int id = 0;
        return (id += context.increment);
    }   

    static string update(string result, Context* context)
    {   
        context.updated = true;
        return result ~ context.token;
    }   

    class API 
    {   
        @before!genID("id") @after!update()
        string handler(int id, string name, string text)
        {
            import std.string : format;

            return format("[%s] %s : %s", id, name, text);
        }
    }   

    auto api = new API();
    auto context = new Context(5, " | token");
    auto funcattr = createAttributedFunction!(API.handler)(context);
    auto result = funcattr(&api.handler, "Developer", "Hello, World!");

    assert (result == "[5] Developer : Hello, World! | token");
    assert (context.updated);
}

[mihails-strasuns]

Oops, forgot to clean up module-wide imports, update incoming.

[mihails-strasuns]

Updated.

[s-ludwig]

Nice, I like the generality. My gut feeling is that it would fit in Phobos, but not really in one of the existing modules*. Weren't there some attempts to introduce some kind of std.meta module? Just this alone wouldn't really warrant its own module, but putting it into the next best fitting module is even worse log term.

Two things that I had in mind while getting a quick overview. Although I knew what the code should do, I had to look twice at the @before/@after annotations. Maybe we can find names that are still short, but slightly more descriptive? Ideally something that tells someone who has never looked at the funcattr module what happens. The other is something that I haven't tested, so it may not apply. The error message for before/after functions with wrong signatures should be as helpful as possible, my fear is that it drowns in a sea of template instantiation errors.

* maybe std.functional after all?

[mihails-strasuns]

The error message for before/after functions with wrong signatures should be as helpful as possible, my fear is that it drowns in a sea of template instantiation errors.

I have tried to cover every possible mismatch case with static asserts with full context info. For example, this is the error message if one of InputAttributes function is attached to parameter with different type:

vibe/utils/meta/funcattr.d(536): Error: static assert  "Calculated input parameter type tuple (double, string, string) does not match vibe.utils.meta.funcattr.__unittestL15_1.API.handler(int, string, string)"
vibe/utils/meta/funcattr.d(432):        instantiated from here: prepareInputAndCall!(string, string)
vibe/utils/meta/funcattr.d(50):        instantiated from here: opCall!(string, string)

If you have noticed some uncovered case or want to propose more useful information to show in error messages - I am all attention :)

Maybe we can find names that are still short, but slightly more descriptive?

I have changed names for those 6 or 7 times in process of working on this. This is hard. Descriptive name for @before would be something like @precalculateParameterByCallingAttachedFunction and I'd really like to have something within 10 symbols. Again, I am open for suggestions - out of good ideas on my own here.

[s-ludwig]

I have tried to cover every possible mismatch case with static asserts with full context info.

That's great! Should I find something (probably not I guess ;) ), I'll shout.

I have changed names for those 6 or 7 times in process of working on this. This is hard. Descriptive name for @before would be something like @precalculateParameterByCallingAttachedFunction and I'd really like to have something within 10 symbols. Again, I am open for suggestions - out of good ideas on my own here.

I'll think about it (also didn't have a really good idea, yet). But anyways, that can be changed after merging.

[mihails-strasuns]

@s-ludwig Seems like you have merged it without running the tests ;) Last change I have made to demonstrate error message has slipped into the commit. Can you change return type of genID from double back to int in master?

[s-ludwig]

Indeed ;) Yes, will do. A pull request tester for the CI server will make for a great follow up feature...