[Ethereum] Override parent method and modifiers

inheritancemodifiersoverride

For example, we have a contract:

contract A {

    modifier checkCaller() {
        require(msg.sender == 0x123);
        _;
    }

    function doSmth() checkCaller {}
}

We make child contract and override function:

contract B is A {
    function doSmth() {
        super.doSmth();
        // ... do more
    }
}

Do I need to explicitly use modifier checkCaller in the child contract B? As I understand super.doSmth() will throw properly. Correct?

Best Answer

Yes, you are correct.

Something I noticed which is worth keeping an eye on is that both modifiers of 'parent' contracts as well as any functions are overwritten by inheritance even when using 'super'.

For example, calling test(0) on B passes and returns 10 (not 5 as one may be led to believe), but fails on contract A.

pragma solidity ^0.4.15;

contract A {
    modifier only (uint test) {
        require(test > 5);
        _;
    }
    function test(uint test) public only(test) returns(uint) {
        return addSome(test);
    }
    function addSome(uint number) internal returns(uint) {
        return number + 5;
    }
}

contract B is A {
    modifier only (uint test) {
        require(test < 10);
        _;
    }
    function test(uint test) public only(test) returns(uint) {
        return super.test(test);
    }
    function addSome(uint number) internal returns(uint) {
        return number + 10;
    }
}

Related Solutions

[Ethereum] Solidity modifiers: good or bad

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.

[Ethereum] Solidity modifiers in library

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!
    }
}

Best Answer

Related Solutions

[Ethereum] Solidity modifiers: good or bad

[Ethereum] Solidity modifiers in library

Related Topic