Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC4626 replace _asset with asset() in order to be easily overrideable #5320

Open
invocamanman opened this issue Nov 26, 2024 · 2 comments · May be fixed by #5322
Open

ERC4626 replace _asset with asset() in order to be easily overrideable #5320

invocamanman opened this issue Nov 26, 2024 · 2 comments · May be fixed by #5322
Milestone

Comments

@invocamanman
Copy link

🧐 Motivation

Overriding asset() function which is defined as virtual might be kinda common practice.
If a project wants to do so it would be nice that all the places that uses the internal variables _asset will be overrided as well.

📝 Details

The internal variable _asset is used in: totalAssets, _deposit and _withdraw. I suggest to replace them with the function asset(), to have a more consistent override

@invocamanman invocamanman changed the title ERC4626 replace _asset with asset() in order to be easily override-able ERC4626 replace _asset with asset() in order to be easily overrideable Nov 26, 2024
@Amxx Amxx added this to the 5.3 milestone Nov 26, 2024
@ernestognw
Copy link
Member

Hi @invocamanman, thanks for raising

I opened a PR for this in #5322. My first impression is that the change would be breaking if an ERC4626Upgradeable contract overrode asset() and then performs an upgrade. Though, I haven't found a concrete security concern.

Another thing that came to my mind is that I've found it weird to call a public function inside an internal one. Nothing wrong with it but I remember we had a similar conversation in another issue.

@Amxx
Copy link
Collaborator

Amxx commented Nov 27, 2024

Another thing that came to my mind is that I've found it weird to call a public function inside an internal one. Nothing wrong with it but I remember we had a similar conversation in another issue.

We do that quite often. I don't think it is an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants