Refactor "expected" to "total" or "aggregate"

[PaulRBerg]

Could you explain the rationale for "expected", @razgraf?

Why not totalAmount and totalRecipients? Or aggregateAmount (as it is written in Solidity)?

The issue with "expected" is two-fold:

1. There's no indication that this is the sum of all airstreams.
2. It assumes an expecting subject; and who's that? The campaign creator? Some airstream recipient? All recipients? Sablier Labs? Vitalik?

---

Edit: saw the definition in the code:

funds required for the entire campaign to conclude

So I gather this is the amount that the MerkleStreamerLL contract expects from the campaign deployer.

My responses:

1. We should not name variables that end users see ("Expected amount" and "Expected recipients" appear in the airstreams dashboard) according to technical interactions
2. The issues above still stand

Thus I posit that total or aggregate would be much, much clearer.

[razgraf]

There's no indication that this is the sum of all airstreams.

That was the point with expected. It's not something set in stone, it is expected to have this amount but as the word preempts, some extra checks for the actual value have to be made.

"Aggregate" is fine, as it follows the contract implementation, but it still doesn't preempt the uncertainty of the amount. Maybe "expected" wasn't the best choice but I hope you understood where I was coming from when choosing this name.

I'll review #20 tomorrow and update the app accordingly.

[PaulRBerg]

That was the point with expected

This seems like a mistake.

It's not something set in stone

But it is set in stone. The aggregateAmount cannot be updated in the smart contract.

it is expected to have this amount but as the word preempts

You've used the passive voice here, evading the 2nd question in the OP. Who expects this? There are multiple entities.

e.g. if I am a recipient, I will expect to receive my own allocation from a claiming page. Seeing an "expected amount" that refers to the aggregateAmount (rather than the user's bespoke allocation) on the same page where eligibility can be checked is a recipe for confused users on Crisp.

it still doesn't preempt the uncertainty of the amount

There's no uncertainty.

Perhaps you mean the current balance - for that, I opened https://github.com/sablier-labs/v2-interfaces/issues/721.

I'll review #20 tomorrow and update the app accordingly

Thank you

[razgraf]

But it is set in stone. The aggregateAmount cannot be updated in the smart contract.

There are no hardcoded guarantees for the claimants the admin will fund that entire amount. That's what I meant with "not set ins tone"

Who expects this? There are multiple entities.

Did not mean to evade anything. Thank you for pointing out and kindly asking me to answer this question. The claimant expects that amount to be fully funded into the contract. The admin is expected to fund that amount into the contract. This was the train of thought that led me to chose "expected".

Seeing an "expected amount" that refers to the aggregateAmount (rather than the user's bespoke allocation)

I can see how this would introduce some confusion, thank you for explaining.

There's no uncertainty.

There can be, there's an assumption that the current balance has to equal the aggregated amount. When this isn't the case, it introduces uncertainty. This is what I meant.

[PaulRBerg]

thanks for the response and for merging #20