0

I'm using solidity 0.7.1 and I seem to be running into issues while inheriting from an abstract contract. Specifically with the open zeppelin library, now I'm not creating an issue there because their code seems correct. Moreover my issue seems rather to be a lack of understanding on my part or a potential flaw in the design of solidity.

The Problem

I'm mainly using 2 abstract contracts from the library ERC20 and ERC20Burnable with ERC20Burnable inheriting from ERC20. Now ERC20Burnable just adds 2 burn methods to ERC20 so it doesn't do anything with the constructor. However when I just inherit from ERC20Burnable in my contract and call upon it as if it had a constructor I expect it to go up the ancestor chain and simply use the constructor of ERC20 since it is inheriting from it. But instead the compiler throws an order. Instead I have to import ERC20 as well, inherit from it too and use it's constructor directly.

Is this the intended behavior? This feels contradictory to the nature of abstraction but I suppose this may be done because security concerns. Any ideas?

0

It should be fine if you inherit from ERC20, but in this case it is not necessary. You can invoke ERC20 constructor directly since it is a base for ERC20Burnable.

contract Token is ERC20Burnable {
    constructor() ERC20("My token", "ToK") public {
    }
}

Solidity has some limitations so perhaps its behavior may be arbitrary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.