Renaming this to "evm-lib"?

[PaulRBerg]

hey @sablier-labs/evm, WDYT about renaming this to one of the following:

• evm-lib
• evm-stdlib
• stdlib (since our EVM repos typically don't start with evm- prefix)

I feel like any name containing the word 'lib' would better communicate the purpose of the logic maintained in this repository.

[andreivladbrg]

I feel like any name containing the word 'lib' would better communicate the purpose of the logic maintained in this repository.

i disagree because we have implemented the comptroller in this repo — which is not a lib nor a standard (std) — it's a contract specifically for sablier business

IMO the term utils covers both the standard (Adminable, Batch, etc.) contracts and the comptroller — but if you don't like it, i'd suggest something like:

• evm-shared
• evm-common
• evm-core

[PaulRBerg]

You're taking the word 'standard' and 'library' too literally, and you're also interpreting them separately.

stdlib comes from C:

https://en.wikipedia.org/wiki/C_standard_library

specifically for sablier business

yes, and the Comptroller is part of Sablier's standard library, which contains common logic use across all repos. It's a good semantic match IMO

if you don't like it, i'd suggest something like:

I don't like shared, common, core as much as stdlib, so if I haven't been able to persuade you that stdlib is good, we can stick with evm-utils.

corecould also be mistaken with the historical V2 Core.

[smol-ninja]

Comptroller is part of Sablier's standard library, which contains common logic use across all repos

Comptroller is not inherited in any of those repos so technically I would not say that Comptroller is common logic. Same comptroller can be used by multiple versions of protocols and same protocol can have multiple comptroller over time. Its the ComptrollerManager that contains the shared logic.

[PaulRBerg]

The Comptroller may not be inherited, but it definitely is used across those other repos, so it still qualifies as 'common logic'.

[smol-ninja]

I am not in favour of renaming this repo, as doing so would introduce refactoring costs without providing any new benefits, beyond a new name. Also, none of the suggested names convey the true purpose of this repository imo. I've discussed this issue with Andrei privately but I am sharing my thoughts on this now:

I have issues with the current structure, as it contains two types of contracts:

1. Abstract utility contracts such as RoleAdminable etc.
2. Comptroller (a standalone contract)

As a result of this, because other repos inherit from this one, the Comptroller cannot directly import the Lockup, Flow, and Airdrop interfaces due to circular import issues. This has forced us to use low-level calls when interacting with core contracts from the Comptroller.

So, I propose the following changes:

1. Create a separate repo for the Comptroller so that it can avoid using low-level calls and instead directly import the relevant interfaces.
2. Then rename this to something more appropriate (from names shared above).
3. I still think the name should not contain lib as the contracts are utility and helper contracts, not libraries, but I am flexible to that.

---

Re. evm- prefix, didn't we decide to add it to make it relevant to EVM repos only, as Solana can also have its own -utils or -libs?

PS: May be mono-repo was not a bad idea after all :))

[andreivladbrg]

as doing so would introduce refactoring costs without providing any new benefits, beyond a new name

we should come up with a metric for the "worthness" of a change — yeah, a rename might be useful if it better represents something, but it includes more steps: refactor, usage updates, audit costs, etc.
in other words: business scalability

[PaulRBerg]

Re naming — shared my thoughts about in response to Andrei. Re lib - you're taking the word literally. A library doesn't refer to Solidity libraries; it refers to a set of shared code that is imported in multiple places. For example, PRBMath is still referred to as a library despite exporting only user-defined value types.

Re Comptroller repo — that sounds good.

Re monorepo — haha indeed. I will build something over the weekend using Just. You might like it.

[PaulRBerg]

we should come up with a metric for the "worthness" of a change

The "worthiness" of a proposal is appraised from debates like this. It cannot be quantified (unless you invent AGI).

Related: https://github.com/orgs/sablier-labs/discussions/16

[smol-ninja]

you're taking the word literally

Fair enough, I see your point, and I agree that the name lib doesn't necessarily have to be containing libraries.

Having said that, could you explain on why you feel evm-utils does not align with the purpose of this repo? You mentioned that lib would communicate it better but perhaps a bit more context would help me understand your perspective.

I will build something over the weekend using Just

Sounds good! Will there be two sub-repos inside this repo: one containing Comptroller package and other for utility contracts? Or something else?

[PaulRBerg]

I simply feel like lib/ stdlib is more standard nomenclature. A Comptroller is not a util. It's a core piece of our EVM protocol. Saying that a core piece resides in a 'stdlib' package makes more sense than in an 'utils' package.

something else?

Something else! I meant moving all EVM code in this new repo. I will show you next week — my ETHCluj presentation got in the way.

[smol-ninja]

A comptroller is not a util but core piece of our EVM protocols. Saying that a core piece resides in a 'stdlib' package makes more sense than in an 'utils' package.

Comptroller isn’t a library either. So, it makes as much sense (if not more) to put it under a -utils than -lib.

Also, if we don't want to focus on the literal meaning of these terms, then it might not also matter if we call it -utils or -lib. One way or another, since the Comptroller is a part of it, the package represents more than just utility or library.

I am open to renaming it to evm-lib, but I don't see it a better name than what we have right now and in addition, it comes up with refactoring overhead. IMO we should revisit this discussion when we have a stronger, more fitting name for it instead of renaming it to evm-lib soon.

[PaulRBerg]

alright