Also, from the developer’s point of view it’s much nicer if library authors are providing functions/macros (as opposed to requiring to use module attributes) because functions/macros can be documented.
What do you mean by that? I wouldn’t want to introduce new functionality, the idea is just to write regular plugs, but having a nicer way to chain them together. So plug Plugs.Auth.Logout when action in [:logout] could be written as @plug Plugs.Auth.Logout just above a logout function, so it’s obvious which function I want to use the plug for. Probably I just didn’t understand what you mean
I believe we considered something as above but we did not go with it because, while it is handful for the cases where you want to apply a plug per action, it is less useful when you want to apply it to all actions. Therefore we preferred a more general mechanism.
We could support both but given we already have a mechanism that works fairly well, we won’t gain much by supporting two of them.
Also, as @wojtekmach said, the plug approach is easier to document compared to @plug.
option, so if we can define multiple plugs in one module attribute without override previous.
However you should not use use this attribute, because:
As it was already pointed: it’s not so easy to document as using macro.
It’s not documented, so it can be changed when public API stays unchanged. For example private methods may use same module attribute structure, but with different name. You need to use plug macro and expect that all inside works until API break release and finally you are protected from that updates by selected version in your deps option in MixFile configuration until you changed it manually.