Getters for stream struct members

[PaulRBerg]

Adds 7 new getters in the ISablierV2 interface:

1. getDepositAmount
2. getRecipient
3. getReturnableAmount
4. getSender
5. getStartTime
6. getStopTime
7. isCancelable

These getters make it easier for third-party devs and integrating partners to read data from Sablier.

See related discussion in #25

[razgraf]

This will be amazing for the lite version of the app or any utility that relies on multicall architecture for data querying (not middleware like the graph). Especially from a DX (dev experience) perspective.

One suggestion would be to build a "data aggregation contract" that includes all these extra methods. The core might not need complex interfaces for its logic, so we could just move them in a separate contract as utilities. Might also save us gas on deployments.

A thing to keep in mind: we should also measure the gas consumption of these read methods. RPC nodes have a "read-only" gas limit which might break multicall. This is a research task but I wanna find out what this limit is and then figure out how many stream interfaces we can "multicall" at once.

[PaulRBerg]

One suggestion would be to build a "data aggregation contract" that includes all these extra methods

Great idea!

The core might not need complex interfaces for its logic, so we could just move them in a separate contract as utilities.

Yes we should move this to a v2-periphery repo once we create that. For the moment though I'd keep the logic in this repo in the main branch, it'd be easier to maintain it that way rather than creating a dedicated branch for it (that branch may become stale).

Might also save us gas on deployments.

Yes, indeed!

[andreivladbrg]

Excellent suggestions from both of you.

[andreivladbrg]

One suggestion would be to build a "data aggregation contract" that includes all these extra methods

Great idea!

The core might not need complex interfaces for its logic, so we could just move them in a separate contract as utilities.

Yes we should move this to a v2-periphery repo once we create that. For the moment though I'd keep the logic in this repo in the main branch, it'd be easier to maintain it that way rather than creating a dedicated branch for it (that branch may become stale).

Might also save us gas on deployments.

Yes, indeed!

I wouldn't merge it to main branch, there will be a lot of extra code. I don't think there is something to maintain, they're just getters functions.

About the code you've written I have nothing to say. Waiting for the special pro functions getSegmentAmounts, getSegmentExponents and getSegmentMilestones.

[PaulRBerg]

I wouldn't merge it to main branch, there will be a lot of extra code. I don't think there is something to maintain, they're just getters functions.

Well they're not just that, they're a holistic part of the repository. E.g. if we implement #29, we should also rename the test contracts for the getters.

Waiting for the special pro functions getSegmentAmounts, getSegmentExponents and getSegmentMilestones.

You can leave a comment about that in #34.

[andreivladbrg]

👍 LGTM