Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

decl_module! allow procedural macro to work on calls function #2782

Closed
gui1117 opened this issue Jun 4, 2019 · 4 comments · Fixed by #6877
Closed

decl_module! allow procedural macro to work on calls function #2782

gui1117 opened this issue Jun 4, 2019 · 4 comments · Fixed by #6877
Labels
Z7-question Issue is a question. Closer should answer.

Comments

@gui1117
Copy link
Contributor

gui1117 commented Jun 4, 2019

Currently we only provide doc attribute for dispatchable call.

But some module maker could want to add more logic make use of procedural macros.

Would it be interesting to allow this users to make use of regular attribute ?

Pros:

  • User can make use of procedural macros to add logic on calls in a very efficient way.

Cons:

  • This expose our implementation into some kind of APIs, the way we implemented this distpatchable function would now be constrained because some user have macros that expect previous result.
  • This is quite touchy in regards to what we auto-generate like Ok(()) for instance.

Finally I feel not in favor of it considering the potential complexity it brings in regards to backward compatibility and APIs.

@gautamdhameja
@bkchr ?

@gui1117 gui1117 added the Z7-question Issue is a question. Closer should answer. label Jun 4, 2019
@bkchr
Copy link
Member

bkchr commented Jun 4, 2019

Do you have any procedural macro in your mind that would be helpful?

@gautamdhameja
Copy link
Contributor

gautamdhameja commented Jun 4, 2019

I was thinking of custom attribute macros which can check a condition or execute some common logic before a function executes. For example - access control, logging, etc.

Also, to @thiolliere's point, the cons are reasonable, but I believe, it should be left to the runtime developer to choose if they want the default functionality (no additional macro) or a customized one. At the moment, there seems to be no choice.

@gui1117
Copy link
Contributor Author

gui1117 commented Dec 10, 2020

This will be fixed by #6877

Basically the macro does it take information from the dispatchables implement block but doesn't touch other attribute macro. Thus other macro can expand and modify the inner content of the dispatchables after the pallet macro attribute has read its information and expanded its stuff (elsewhere, it doesn't touch the implement block).

For instance transactional annotation is supported without any change in the pallet attribute macro.

Though what is not expanded is a macro which would modify the signature of the dispatchable.
E.g. if a macro add an argument to a dispatchable, then, as pallet macro is executed first, pallet macro doesn't have the added argument information and the pallet macro expansion will be invalid.

@ghost ghost closed this as completed in #6877 Dec 24, 2020
@gui1117
Copy link
Contributor Author

gui1117 commented Dec 24, 2020

So if someone need to execute a macro prior to pallet macro then he currently cannot do easily.

Maybe we provide a macro helper to execute some macro defined inside a macro:

execute_foo! {
#[pallet]
mod pallet {

....
foo!{ ... }
}

So execute_foo would search for keyword foo! and then take its input and then execute it and replace foo! {.. } with the result.

If ppl have strong need for it then I can try to come up with something.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Z7-question Issue is a question. Closer should answer.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants