Normalize address vs. interface usage

[pegahcarter]

It can be a confusing developer experience when using a library that references different contracts as interfaces vs. addresses. For example, these are both contracts:

https://github.com/bgd-labs/aave-address-book/blob/f73f77ca03f61c7bc3b6899d173e96ea200cf529/src/AaveV3Ethereum.sol#L37-L41

This could be a problem when importing a library to use within a contract to reference. For example, this compile would succeed:

import {AaveV3Ethereum} from "aave-address-book/AaveV3Ethereum.sol";
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";

contract MyContract is Ownable {
    constructor() Ownable(AaveV3Ethereum.ACL_ADMIN)
    ...
}

But this compile would fail:

import {AaveV3Ethereum} from "aave-address-book/AaveV3Ethereum.sol";
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";

contract MyContract is Ownable {
    constructor() Ownable(AaveV3Ethereum.CONTROLLER)
    ...
}

My opinion is to have every contract referenced as an address and provide an additional library variable prepended with I to reference the same contract as an interface. It would add some bloat to the libraries but given they are auto-generated and lightweight I don't see it as an issue.

[sakulstra]

@pegahcarter, i have no to strong opinion on this.

We added interfaces for addresses that in governance-proposals are usually used as Interface and omitted them on addresses that are usually just used as contract (if at all).

Changing this now would be a huge breaking change, bloat contract verification (as all these contract will end up on etherscan even when only a single address/interface is used). Leaning towards thinking it's not worth it, given you can simply fix your example by casting to address.