Suggestion to rename the "create" function to "stream"

[PaulRBerg]

Due to the streamId argument, all functions can be inferred to be about streaming. But there are two exceptions - the create and the createWithDuration functions.

It is not immediately obvious that these functions are creating streams. One would need to have the wider context on what Sablier is to infer that.

What if we renamed the create and the createWithDuration to simply stream? (noting that it is possible to overload functions in Solidity, as long as the arguments differ, and in this case they do)

There's something about the simplicity and actionability of stream that makes me like it a lot. I came up with this idea while brainstorming (on my own) what name to give the gross deposit amount. grossDepositAmount is good from a clarity point of view, but it's rather verbose. grossAmount, on the other hand, does not communicate what the amount is, but that is also due to the lack of context in the function name itself. That's when I thought about renaming create to stream - if we make this change, then we could potentially use the grossAmount naming, because the purpose of the amount would be inferred from the stream verb.

Cc @razgraf, @andreivladbrg.

[PaulRBerg]

On second thoughts, I don't like stream that much, because it would lead to an inconsistent use of the term stream. We're always using it as a noun, but in my proposal herein, I am suggesting to use it as a verb.

A better fit would be createStream.

[razgraf]

I find it pretty clear (from the perspective of an outsider) that "create" is meant to add a new item. In the context of streaming, the new item is, of course, a stream. It's not like we have other types of 1st-class entities. Therefore, I'd keep the create particle.

On the suggestion of overloading functions, I don't think it's quite the right fit. Overloading is very powerful when working with lower level methods, especially in the context of overloading operators. For example, I'm expecting an add function or the + operator to perform addition regardless of number of arguments add(1,2); add(1,2,3) or types add("a", "b");. TL;DR; Similar outcome with an arbitrary number of similar arguments.
Our create feature takes different arguments and has different temporal semantics, enough to make the two "flavors" different in assumptions. I believe this would require separating them by name, for clarity.

---

Extra suggestion: we could rename our methods to createWithRange and createWithDuration to make the distinction clearer.

[PaulRBerg]

It's not like we have other types of 1st-class entities

This is a good point.

Our create feature takes different arguments and has different temporal semantics, enough to make the two "flavors" different in assumptions. I believe this would require separating them by name, for clarity.

I agree.

we could rename our methods to createWithRange and createWithDuration to make the distinction clearer.

Funnily enough, this is what I ended up doing even before seeing your reply here. I changed my mind in the meantime, and I no longer fancy either stream or createStream. Two overloaded functions createStream can be confusing, especially on Etherscan.

[PaulRBerg]

Locking, in #220 I ended up going for:

• createWithRange
• createWithDurations
• createWithMilestones
• createWithDeltas

To provide more context and differentiation between the functions.