Closed ZigBalthazar closed 8 hours ago
If you import @stdlib/ownable
and use the Ownable
trait, you get something like this:
import "@stdlib/ownable";
contract Foo with Ownable {
...
init(owner: Address) { self.owner = owner }
receive(msg: Mint) {
self.requireOwner(); // -- very close to a decorator, but does not complicate the language further
require(self.mintable, "Can't Mint Anymore");
self.mint(msg.receiver, msg.amount, self.owner); // (to, amount, response_destination)
}
}
Closing this for now, feel free to re-open if there are more considerations
sometimes some smart contract functions need to check some conditions modify some states out of function scope or add some check or logic to function without changing the function body(decorator pattern). for example: if we needed to check the owner's permission for this
receive
:we have to load the context and then check the sender's address to be equal to the owner's address by using
require
:if we can define some modifier(or decorator) function to add the owner checking condition to this
receive
we get these points:in
Tact
I think(not sure) some reserved words likevirtual
orget
are like modifiers(decorator) because they change the function behavior(override
: let function to be overridden and,get
: let function to be public). I suggest having some modifiers to allow developers to write the logic. for example(regarding to prev example):now write the mint receive again:
I can reference you to the Solidity Modifier or the Nestjs decorators