Skip to content
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

Combine StablePool traits into one #30

Merged
merged 6 commits into from
Jul 15, 2024
Merged

Combine StablePool traits into one #30

merged 6 commits into from
Jul 15, 2024

Conversation

JanKuczma
Copy link
Collaborator

This PR combines StablePool and StablePoolView into one trait. It also introduces a few less significant changes:

  • refactor "getter" function so they don't require &mut self
  • rewrite some comments and function names

@JanKuczma JanKuczma requested a review from woocash2 July 12, 2024 19:21
/// Compute the amount of LP tokens to mint after a deposit
/// return <lp_amount_to_mint, lp_fees_part>
/// Given `deposit_amounts` user want deposit, calculates how many lpt
/// is required to be burnt.
Copy link
Contributor

@woocash2 woocash2 Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minted, not burned? (also use plural? (are))

/// return <lp_amount_to_burn, lp_fees_part>
/// all amounts are in c_amount (comparable amount)
/// Given `withdraw_amounts` user want get, calculates how many lpt
/// is required to be burnt
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are, not is?

/// NOTE:
/// If the pool contains a token with rate oracle, this function makes
/// a cross-contract call to the `RateProvider` contract if the cached rate is expired.
/// This means that the gas cost of the contract methods that use this function may change,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'vary' instead of 'change'? Feels like a better fitting word 😛

amounts: Vec<u128>,
) -> Result<(u128, u128), StablePoolError>;

/// Calculate ideal deposit amounts required
/// Estimate ideal deposit amounts required
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would stay with 'Calculate' here and below. 'Estimate' suggests some randomness 😛. I suppose that 'Estimate' here was supposed to account for precision errors. I think 'Calculate' is still a good word, even in presence of precision errors.

Copy link
Contributor

@woocash2 woocash2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I've got a few remarks:

  • I don't understand the purpose of merging StablePool with StablePoolView. I've got nothing against it, but I would like to understand the reason (if there's any)
  • You made all getters to use immutable reference, which required you to remove rate updates from them. It makes sense to have an immutable getter, but consider a scenario when the contract is not used for a long long time for whatever reason. Someone uses a getter to for instance get the mint liquidity for given amounts (they are consideing putting in the liquidity, but want to estimate lpt first). Then they will get very outdated results. Pls consider getting back to mut in these getters which use rates. If you disagree, we can discuss that.

@JanKuczma
Copy link
Collaborator Author

  • I don't understand the purpose of merging StablePool with StablePoolView. I've got nothing against it, but I would like to understand the reason (if there's any)

The reason was purely cosmetic. Imho it simplifies the contract.

  • You made all getters to use immutable reference, which required you to remove rate updates from them. It makes sense to have an immutable getter, but consider a scenario when the contract is not used for a long long time for whatever reason. Someone uses a getter to for instance get the mint liquidity for given amounts (they are consideing putting in the liquidity, but want to estimate lpt first). Then they will get very outdated results. Pls consider getting back to mut in these getters which use rates. If you disagree, we can discuss that.

The getters still use updated rates for calculations. The difference is that now the getters don't update the cached rates in the contract.

Copy link
Contributor

@woocash2 woocash2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, sorry, didn't notice that 😉

@JanKuczma JanKuczma merged commit 5123a07 into main Jul 15, 2024
1 check passed
@JanKuczma JanKuczma deleted the fixes branch July 15, 2024 08:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants