-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: use 'handlers' more frequently #2883
Comments
Not sure about this one tbh, as I think the term "handler" is more overloaded and ambiguous than "instruction". Handler only makes sense in the context of the thing that its handling, e.g. instruction.
Maybe it could make sense to change this if we didn't have a 3+ years history of using "instruction", but currently I don't think this adds enough benefits to justify this breaking change, especially considering the popularity of |
That's true. An instruction being processed by a handler does make more sense than an instruction being processed by an instruction though.
This is true, there is a change albeit fairly easier to migrate to. Consider the size of each audience:
I imagine the latter is at least one, perhaps two orders of magnitude larger. |
Various groups on Solana struggle to explain the process of instruction processing due to the overload of the term 'instruction'
Many Solana docs mention "instructions being processed by instructions", which doesn't make sense (instructions don't process themselves), particularly to programmers that haven't built an onchain program previously.
Anchor 0.29 made everyone's lives better by popularising the term 'handler' for the thing that does the processing:
This works really well.
It would be good to use handler in a few more places in Anchor:
program.methods
toprogram.handlers
in the Anchor TS clientsrc/instructions
dir tosrc/handlers
in the multiple files templateThe text was updated successfully, but these errors were encountered: