Solidity Modifiers – Implementing Modifiers in a Library

librarymodifierssolidity

Isn't it possible to define modifiers in libraries? I'm really asking myself why, because thats some functionality you would need over and over again.

If I would like to hypothetically implement some ownable modifier and let that be used in many of my contracts, I would have to implement it in every of my contracts or use another contract (no library), that provides the modifier.

I've seen https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/ownership/Ownable.sol and they implement the functionality also as a contract rather than a function as, I guess, modifiers cannot be accessed from Solidity libraries?

My question: should I now implement my modifiers in my abstract contracts or define modifiers in a contract on its own like the Zeppelin guys did? Whats the up/downsides?

Best Answer

Library may define and use modifiers, but it cannot export them. Modifiers are compile-time feature, kind of macros. Modifier code is substituted by compiler to every method that uses this modifier. For complex modifiers this may be a problem, but you may always move modifier's logic into a function (library function, probably), and then refer to this function from within modifier. You may also implement common modifiers in interface to share them among several contracts:

library Foo {
    modifier nonZero (uint x) {
        require (x != 0);
        _;
    }

    function isPrime (uint x) public nonZero (x) returns (bool) {
        // Complicated logic here
    }
}

interface Bar {
    modifier onlyPrime (uint x) {
        require (Foo.isPrime (x));
        _;
    }
}

contract Zoo is Bar {
    function fooBar (uint x) public onlyPrime (x) {
        // Here we know that x is prime!
    }
}

Related Solutions

[Ethereum] Can Solidity function modifiers access function arguments

At the point where you use the modifier, the function arguments are already in scope. This means something like the following is possible:

contract C {
  modifier restrictTargetType(address target, uint contractType) {
    require(contractTypes[target] == contractType);
    _;
  }
  function f(address target, uint contractType) restrictTargetType(target, contractType) {
    ....
  }
}

There is no generic way to provide access to the function arguments, though.

Solidity Modifiers – Are They Good or Bad for Contract Design?

I often find I want a software client to be able to check but I also want a modifier for readability, so it often ends up like this:

modifier onlyIfAllowed() {
  require(isAllowed(args));
  _;
}

function isAllowed() public view returns(bool allowed) {
  allowed = ...
}

function safer() public onlyIfAllowed ...

Of course, it would also be fine to do that in-line.

function inline() public {
  require(isAllowed());
  // carry on

Ultimately, it is a matter of personal preference. I find it more readable to go like this:

function tricky() public onlyOwner onlyIfAllowed onlySomethingElse { ...

... so the actual purpose of the function doesn't get mixed up with repetitive steps. It's more DRY, in my opinion. Not everyone agrees. The Vyper team, for example, consider modifiers an anti-feature that obscures important logic that they feel should be in-line.

Hope it helps.

Best Answer

Related Solutions

[Ethereum] Can Solidity function modifiers access function arguments

Solidity Modifiers – Are They Good or Bad for Contract Design?

Related Topic