You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My objective is to streamline our realm structure. Rather than having each realm cluttered with lists like faucets, admins, whitelisted, and various assertIsXXX functions, we should centralize these responsibilities. I envision the chess_variables realm to manage these configurations.
Instead of having individual methods like assertIsFaucet() followed by updateFaucet(newAddr std.Address) {assertIsAdmin(); faucetAddr = newAddr}, we could simply integrate import gno.land/r/demo/chess_variables and utilize chess_variables.AssertIsFaucet(). The management and update functions would be encapsulated within the chess_variables realm.
This approach minimizes redundancy and boilerplate code. It's a design pattern I believe organizations should adopt—having a designated variables realm in their namespace. This way, other contracts can focus on their primary functionality without the added weight of managing basic variables, such as the migration of an adminAddr.
I recommend taking a look at my draft PR in the main repository. There, I've attempted to template these common patterns, aiming for more succinct contracts that utilize established patterns: gnolang/gno#880.
The text was updated successfully, but these errors were encountered:
moul
changed the title
Implement a r/demo/chess_variables
Implement a r/demo/chess_variablesSep 26, 2023
My objective is to streamline our realm structure. Rather than having each realm cluttered with lists like
faucets
,admins
,whitelisted
, and variousassertIsXXX
functions, we should centralize these responsibilities. I envision thechess_variables
realm to manage these configurations.Instead of having individual methods like
assertIsFaucet()
followed byupdateFaucet(newAddr std.Address) {assertIsAdmin(); faucetAddr = newAddr}
, we could simply integrateimport gno.land/r/demo/chess_variables
and utilizechess_variables.AssertIsFaucet()
. The management and update functions would be encapsulated within thechess_variables
realm.This approach minimizes redundancy and boilerplate code. It's a design pattern I believe organizations should adopt—having a designated variables realm in their namespace. This way, other contracts can focus on their primary functionality without the added weight of managing basic variables, such as the migration of an
adminAddr
.I recommend taking a look at my draft PR in the main repository. There, I've attempted to template these common patterns, aiming for more succinct contracts that utilize established patterns: gnolang/gno#880.
The text was updated successfully, but these errors were encountered: