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: https://github.com/gnolang/gno/pull/880.
My objective is to streamline our realm structure. Rather than having each realm cluttered with lists like
faucets,admins,whitelisted, and variousassertIsXXXfunctions, we should centralize these responsibilities. I envision thechess_variablesrealm 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_variablesand utilizechess_variables.AssertIsFaucet(). The management and update functions would be encapsulated within thechess_variablesrealm.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: https://github.com/gnolang/gno/pull/880.