How to ensure divergence while maintaining duplicated code

[0xAkuti]

gm, since we want to create this library without inheritance there is and will be duplicated code, e.g., between ERC20Facet.sol and LibERC20.sol. When updating this in the future, it might lead to divergent code within different files if not carefully maintained. I think right now it's fine but as the library grows and gets more complex there might be cases where changes are missed.
What are your thoughts about that? Do you see it as a potential issue?
I thought, how about we create a code generation pipeline and syntax so that code only is written once and then automatically applied everywhere needed via this pipeline.

[cyotee]

I have the same concern. I'm trying to use Compose in my own project so the storage will be consistent so code can be reused.

And the replication of storage library code into the Facets seems like a needless complication.

Why not just import the storage libraries, and use them in the Facets? Make the Facets just a wrapper around the library functions to expose them for us in a proxy? Still no inheritance and still readable because all the logic is in the library.

I know the point is devs should just use the deployed instance. But they will still need to include the storage libraries in their code so they can access the same storage.

Trying to solve this with a custom build step to generate code is further complicating the problem.

[mudgen]

gm, since we want to create this library without inheritance there is and will be duplicated code, e.g., between ERC20Facet.sol and LibERC20.sol. When updating this in the future, it might lead to divergent code within different files if not carefully maintained. I think right now it's fine but as the library grows and gets more complex there might be cases where changes are missed.
What are your thoughts about that? Do you see it as a potential issue?

Once we deploy ERC20Facet and other facets to blockchains, I don't plan to change them anymore. So we won't have to worry about maintaining them in the future.

Compose standard library of facets is written for users creating their projects -- and the end users will use them onchain, not off chain, though perhaps some will. But when the users want to look at the source code of facets I want it to be as easy and straight forward as possible.

Why not just import the storage libraries, and use them in the Facets? Make the Facets just a wrapper around the library functions to expose them for us in a proxy? Still no inheritance and still readable because all the logic is in the library.

@cyotee I suggest you do that if you want to. The inheritance and other rules only apply to Compose, they don't apply to what people want to do in their own projects.

[cyotee]

I know it doesn't apply to what people do in their own projects.

I mean, how do you ensure the deployed facet matches the library being used? Why bother maintaining a library with business logic if it's not being used in the Facet? The problem is you're introducing two paths, seeming because wrapping an internal function to expose it is somehow "unreadable".

[mudgen]

how do you ensure the deployed facet matches the library being used?

Before a facet is deployed it is visually checked to be sure that its diamond storage matches its library file.

After the facet is deployed the library file in Compose is never changed again. We may even technically do something to prevent it from being changed.

Why bother maintaining a library with business logic if it's not being used in the Facet?

Because the library file can be used in custom facets written by users that compose with it. That's the purpose of the library files.

wrapping an internal function to expose it is somehow "unreadable".

No, it isn't "unreadable", but it is somehow "less" readable.

The core of this is really about who the code is written for. It isn't written for me, and not for the developers creating Compose. It's for people who want to read and understand the facets, such people as random security auditors, users of applications that use Compose who want to understand what the application does etc.

[cyotee]

It's for people who want to read and understand the facets, such people as random security auditors, users of applications that use Compose who want to understand what the application does etc.

Let me try making my case in a different way.

Replicating the code makes it harder to verify.

If you simply wrapped the library logic in the Facet, then user could programmatically verify easily by pulling the source code for the Facet address.

https://getfoundry.sh/guides/project-setup/clone-a-verified-contract.html

Pull the source code for the Facet. Check that the included library matches the one being reused. All possible using existing tools.

By replicating, you're going to need a more complicated and fragile process to verify the reused logic is the same. Like a manual review.

I'm not sure your intended audience exists. Whom is going to be reviewing the code that won't understand a wrapped library call. But will understand they need to manually review the facet and library being reused to confirm there are no changes.

function balanceOf(address account) external view returns (uint256) { return LibERC20.balanceOf(account) }

Is not less readable then manually reviewing two code blocks to verify they match.

[mudgen]

Okay, thanks @cyotee