algorand
Inconsistencies in Transaction type definitions make finding and understanding the information less easy.
The transaction reference page does not mention Asset Destroy in the TOC or as a header, nor Asset Create. However, once this transaction type is discovered, it can be found on a page with much more info .
This seems inconsistent with the way the Asset Transfer transaction type is documented as offering Asset Transfer , Accept (Opt In) and Clawback. Also Asset Accept is used as a synonym for Opt In, which is a further confusing inconsistency.
If the axfer txn type can be used for very different operations (Transfer, Opt In and Clawback), if acfg followed suit (for Create , Update and Destroy) things would be clearer.
However, going further, grouping transaction types into general area, "axfer" for anything to do with account/asset relationships and "acfg" for anything to do with CRUD on an asset type, is IMO a complication in the first place.
If each transaction type was given its own label, or sub type eg: "acfg/destroy" (or split into 2 fields) then that would make class modelling of the transactions in JSON specs, APIs, SDKs and automatic deserialisation a lot easier.
The confusion passes into the SDKs: These are currently designed as offering a general all-encompassing Transaction object with a bunch of CreatePaymentTransaction, CreateAssetDestroyTransactions, etc etc methods, which is poor OO design. A generally more helpful and easily maintained approach is to have the Transaction classes subclassed according to specific type and then allow serialisers/deserialisers/indexers etc etc switch on an explicit type (acfg/destroy). Rectifying this in the current SDKs needs work arounds to select transaction type during serialisation.
Describe the solution you'd like
- Update the Txn Ref docs with the missing implicit transaction types.
- Add a new field or modify the existing field so that each transaction type from Asset Destroy to Call Application is uniquely identified and have all these modeled in a proper OO way throughout the whole system.
Describe alternatives you've considered Being eternally sad.
Additional context
