3

Why use interfaces? I've heard this allows for easier bug fixes down the road, but with or without an interface, wouldn't you have have to scrap the bugged contract entirely?

1

Interfaces are a good way to let people understand how to use a contract.

On a purely utilitarian view, if you keep your contracts into different files, interfaces allow you to avoid cross-reference compilation errors:

I.sol:

contract I {
    function deployB();
    function doSomething();
}

J.sol:

contract J {
    function doOnI(address i);
}

A.sol:

import "J.sol";
import "B.sol";
contract A is I {
    function deployB() {
        new B();
    }
    function doSomething() {}
}

B.sol:

import "I.sol";
import "J.sol";
// You would not be able to import A.
contract B is J {
    function doOnI(address i) {
        I(i).doSomething();
    }
}
  • So if "A" creates a contract "B" which wants to use a function defined in "A", contract "B" must use the interface of "A"? – ethereal Oct 16 '16 at 23:35
  • Yes, that is always true as the Solidity compiler will replace A's function calls with their equivalent in bytecode. However, here, because of the import cyclicality, we need to use interfaces. – Xavier Leprêtre B9lab Oct 17 '16 at 9:05
  • Ok great, so there is no security benefit to using interfaces? – ethereal Oct 17 '16 at 18:55
  • Not that I know of. After all, a Solidity contract is compiled into bytecode, which has no concept of interface. If your bytecode is there and can be called, it does not matter whether you used interfaces. – Xavier Leprêtre B9lab Oct 17 '16 at 22:30

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.