Split SablierV2OpenEnded.sol into SablierV2OpenEndedBase.sol and SablierV2OpenEnded.sol

[smol-ninja]

^{Originally discussed in this issue.}

Context

As decided here, we've included peripheral functions in SablierV2OpenEnded.sol which has resulted into one big contract. There are a few issues with it:

1. Too many public functions in the same contract make it difficult to review the code.
2. Some functions just call other public functions. For example, createAndDepositMultiple simply makes calls to createMultiple and depositMultiple. This makes it difficult to separate core logic from the peripheral logic.

Proposal

I would like propose to separate functions that can be classified as peripheral.

1. Define a new contract called SablierV2OpenEndedBase.sol in the abstracts folder. Thereby moving all the internal and core functions here.
2. SablierV2OpenEnded would inherit from SablierV2OpenEndedBase and implement periphery related functions.

Public functions in SablierV2OpenEndedBase

1. adjustRatePerSecond
2. cancel
3. create
4. deposit
5. restartStream -> how about we call it restart?
6. refundFromStream -> how about we call it refund?
7. withdraw

Public functions in SablierV2OpenEnded

1. cancelMultiple
2. createAndDeposit
3. createMultiple
4. createAndDepositMultiple
5. depositMultiple
6. restartStreamAndDeposit
7. withdrawMultiple
8. withdrawMax

[smol-ninja]

Leaving it here: https://github.com/boringcrypto/BoringSolidity/blob/78f4817d9c0d95fe9c45cd42e307ccd22cf5f4fc/contracts/BoringBatchable.sol

Could be useful for batch txs

[andreivladbrg]

Curious about your opinion on this @razgraf. I think it would be more complex on the app side if we have "normal" functions and then batch functions with bytes params instead of classic arrays.

IMO we should stick with the current version

[razgraf]

I would definitely like to have named parameters and structs instead of encoded bytes for the methods as it makes debugging easier.

Bytes are probably more efficient and scalable (that batch method acts a bit like execute(bytes) in safes) but DX-wise, not sure we need it right now.

[andreivladbrg]

agree

[smol-ninja]

Fair point @razgraf.

The objective of this discussion is to figure out how to maintain SablierV2OpenEnded contract. As per the OP, SablierV2OpenEnded.sol would contain functions related to batch txns while SablierV2OpenEndedBase.sol would contain core functions. This my not look right as one would expect core functions to be present in the SablierV2OpenEnded.sol file.

An another way of doing it could be to have batch functions in SablierV2OpenEndedMultiple.sol and core functions in SablierV2OpenEnded.sol but then on etherscan, it will always be visible as SablierV2OpenEndedMultiple.sol.

[razgraf]

I've added some more related thoughts in #10.

[smol-ninja]

I am closing it for now in favour of this ongoing discussion about batch function. Please feel free to re-open it when we want to continue the discussion on splitting the contract into two parts.