refactor: rename compute_budget_instruction_details for accuracy #4409
Conversation
…tails to better reflect its purpose
tao-stones
force-pushed
the
refactor-rename-compute-budget-instruction-details
branch
from
5b7f854 to
d788b23
Compare
| fn signature_details(&self) -> &TransactionSignatureDetails; | ||
| fn compute_budget_instruction_details(&self) -> &ComputeBudgetInstructionDetails; | ||
| fn instruction_details(&self) -> &InstructionDetails; |
There was a problem hiding this comment.
my one concern with the rename is that it seems like signature_details are also details about the instructions? InstructionDetails seems too generic almost, wdyt?
There was a problem hiding this comment.
If the details still refer to compute budget, I prefer the naming to mention it, lest we mistake it for a generic instruction.
There was a problem hiding this comment.
my one concern with the rename is that it seems like signature_details are also details about the instructions? InstructionDetails seems too generic almost, wdyt?
This is the first step to combine signature details into instruction details (as the poc we discussed some times ago), hopefully saving one iteration over instructions when there is one "details" for runtime-transactions.
If the details still refer to compute budget, I prefer the naming to mention it, lest we mistake it for a generic instruction.
Good point, makes me think all "details" definition should be in runtime-transaction crate, could leave ops to "details" (such as get, try_from etc) in proper crates.
I'll play around for both feedbacks.
tao-stones
deleted the
refactor-rename-compute-budget-instruction-details
branch
|
|
|
close this, prefer #4525 for full stake refactor. |
Problem
This renaming was stripped out from #3799 to reduce its change size for backporting. Be nice to rename to
instruction_detailsto better reflect its actual purpose.Summary of Changes
Fixes #