feature: use 'handlers' more frequently

[mikemaccana]

Various groups on Solana struggle to explain the process of instruction processing due to the overload of the term 'instruction'

• Instruction, the call to a function in an onchain program, inside a transaction
• Instruction, the function in an onchain program that processes these incoming calls

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:

pub fn handler(ctx: Context<Initialize>) -> Result<()> {
    Ok(())
}

This works really well.

• "Instructions are handled by instruction handlers" makes logical sense
• Many developers are familiar with web servers, where requests are handled by request handlers.
• Foundation (specifically Nick and I) got inspired by Anchor and added instruction handler and clarified instruction to the 'Terminology' doc, used by Foundation, Anza and many others as the official definition of most terms on Solana.

It would be good to use handler in a few more places in Anchor:

• Rename program.methods to program.handlers in the Anchor TS client
• Rename src/instructions dir to src/handlers in the multiple files template

[acheroncrypto]

Various groups on Solana struggle to explain the process of instruction processing due to the overload of the term 'instruction'

• Instruction, the call to a function in an onchain program, inside a transaction
• Instruction, the function in an onchain program that processes these incoming calls

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:

pub fn handler(ctx: Context<Initialize>) -> Result<()> {
    Ok(())
}

This works really well.

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.

It would be good to use handler in a few more places in Anchor:

• Rename program.methods to program.handlers in the Anchor TS client
• Rename src/instructions dir to src/handlers in the multiple files template

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 src/instructions in many of the production program repositories and countless examples/tutorials.

[mikemaccana]

Handler only makes sense in the context of the thing that its handling, e.g. instruction.

That's true. An instruction being processed by a handler does make more sense than an instruction being processed by an instruction though.

we have a 3+ years history of using "instruction"

This is true, there is a change albeit fairly easier to migrate to.

Consider the size of each audience:

• people that have previously written a program using Anchor
• people that will potentially write a program using Anchor in future

I imagine the latter is at least one, perhaps two orders of magnitude larger.