Amounts struct for encapsulation

[PaulRBerg]

In PR https://github.com/sablier-labs/flow/pull/205/files, I introduced a dichotomy between amounts:

1. normalized
2. denormalized

Side note: in the future, we might rename these to scaled and raw, but never mind that for now

The idea is to introduce a new Amounts struct that encapsulates the normalized and denormalized amounts. Doing so would allow us to:

• Return the Amounts struct in all debt functions
• Merge the refundableAmountOf and normalizedRefundableAmountOf functions into a single function that returns a struct (related: Rename current "refundableAmountOf" and introduce non-normalized counterpart #202)
• Emit a struct instead of two amounts (related: Include both the normalized and the denormalized amount in the transfer events #204)
• Generally, encapsulate amounts whenever helpful throughout the code

cc @sablier-labs/solidity.

[smol-ninja]

Interesting idea! I instantly liked it when you proposed it 3 days ago. But while reviewing the PR, I think that it would be an overkill for the smart contract interface. It's something that would be resolved at the UI level anyway.

I also have my doubts about why refundableAmountOf should have a "denormalized" version whereas all other functions only have normalized versions. What's so special about it? (If you have explained it at other places, please feel free to point me at it).

Emit a struct

Though I agree that it is a good idea to include both versions in the events for indexers (related: #204 (comment)) but having two variations for all the amount values (either in the Struct format or two functions) will be redundant at the contract level.

Given that 18 decimals are the most popular assets, the users will always see the same values for both the struct variables. The only exception would be USDC but that would be taken care of in the UI.

I'd love to hear your comment on this.

[PaulRBerg]

Thanks for your feedback.

It is helpful to provide a normalized version of refundableAmountOf because the refund function requires a normalized value as input. The frontend would find this utility function helpful.

Good point about most popular tokens being 18 decimals. This makes me less convinced of the original proposal.

[PaulRBerg]

cc @sablier-labs/frontend can you confirm that you would find it helpful to have a Solidity utility function that provides the normalized refundable amount of a Flow stream, so that you can pick up the said amount and pass it as an input to the refund function?

[andreivladbrg]

It is helpful to provide a normalized version of refundableAmountOf because the refund function requires a normalized value as input. The frontend would find this utility function helpful

Not if we change this, see my proposal here #202

[PaulRBerg]

Correct, your proposal there changes this.