On Tuesday, 18 March 2014 at 10:36:31 UTC, Yuriy wrote:
However, it's clearly seen from your example in vibe.d that using "decorators" expects users to know how to explicitly "evaluate" them. Otherwise, your "decorated" code could be misused if used "intuitively". Such approach effectively leads to at least two places in code, where you need to know about the logic of an attribute.
In vibe.d context it is intentionally designed that way. Same classes can be re-used as is for any other request handling - additional annotations make sense only within REST context. Splitting allows to achieve perfect decoupling here.
In case you want to make persistent adjustment, approach (2) is recommended. It can effectively achieve the same result as true decoration with only difference that explicit mixin is required to hint both reader and compiler what is actually happening here.
In real project it is up to your personal judgement which approach fits use case better.
I totally agree that modifying decorators could add another way of shooting your foot, but it seems to me that it's benefits are worth it. Besides, decorating a definition with an uninstantiated template would not break current syntax and current UDA logic. Also it could be potentially implemented by lowering, as described in my first message.
I think it is possible but gain does not seem to be worth complications. On a related notes, I'd also love to see "contained" AST macros, similar to how string mixins are always explicit.
Also, don't we love C++ for it's infinite number of ways to shoot your foot? =)
Well.. no. Not really :)
