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

Add namespace to Upgrades #300

Merged
merged 6 commits into from May 6, 2022

Conversation

andrew-fleming
Copy link
Collaborator

This PR integrates namespace to the Upgrades library, Proxy contract, and mock proxy contracts. This PR also proposes to reorganize the Proxy methods. Finally, this PR proposes to update the Proxy docs with the changes.

Copy link
Contributor

@martriay martriay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good!

Proxy_only_admin()
Proxy_set_implementation(new_implementation)
Proxy._only_admin()
Proxy.set_implementation(new_implementation)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since it's up to the devs to protect the set_implementation function, shouldn't we signal this by making it a type B function aka a building block/not meant to be exported as-is, and name it _set_implementation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

otoh this is going to happen a lot (libraries with many B functions), I'm doubtful now

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I'm actually in favor of that, but yes, it definitely is going to happen a lot. I'll update using the type B syntax. If there's objections after seeing it, we can discuss/reassess further

# Initializer
#

func initializer{
Copy link
Contributor

@martriay martriay May 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should call it constructor like the rest of the namespaced libraries, no? Or at least open yet another discussion :p

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha so many discussions! Yeah, using constructor is probably best. I was thinking this was a special case, but it really operates in the same way the other constructor/initializers do

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the latest commits, the Proxy library's initializer is changed to constructor, but I kept the initializer function name in the implementation contracts. My thought process is to ensure users don't think to use initializer in the decorated @constructor. See example here. Since it must be invoked after deployment, I think initializer is more appropriate

Copy link
Contributor

@martriay martriay May 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely, I had something similar in mind.

# Guards
#

func _only_admin{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you think of prepending guard-like functions with assert_? like assert_only_admin. I think it's pretty clear what it does, and it would be consistent across the language and with other codebases.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was actually thinking that the guard functions look a little naked when they're used. Prepending with assert_ is a really good idea

@andrew-fleming andrew-fleming marked this pull request as draft May 5, 2022 17:09
@andrew-fleming andrew-fleming marked this pull request as ready for review May 5, 2022 19:51
@martriay martriay merged commit 0e54d4d into OpenZeppelin:main May 6, 2022
@andrew-fleming andrew-fleming deleted the namespace-upgrades branch May 6, 2022 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants