Meta-programming interface - ERC165 support

[axic]

While this topic can be fairly big and we have a couple of issues open already here I only suggest a fairly small, non-intrusive addition:

meta(<contract name>)

to return a meta object (similar to block, etc.). This would have the following defined currently:

• .signatures returns bytes4[] corresponding to the method signatures of the contract
• .name returns string as the name of the contract

The signatures could be utilised by proxy / filter contracts and for a way to implement interface checking between contracts (along the lines of ethereum/EIPs#165).

Two other possible methods:

• .pragma(<key>) returns string of the actual pragma value or empty string if not set (or should the return type depend on the pragma type?)
• .super returns meta[] corresponding to all the direct superclasses

[axic]

This could be augmented by compile-time execution of certain pieces of code. It should be possible to execute pure functions during compile time given there's a VM for the intermediate language of the compiler.

[VoR0220]

Following

[chriseth]

I would prefer type instead of meta and baseContracts instead of super (super has a special meaning). Since we do not yet assign pragmas to contracts and arrays are quite hard to do, I would postpone them.

[axic]

Using the above meta programming interface, ethereum/EIPs#165 can be implemented as a library:

contract ERC165 {
    function interfaceID() constant returns (uint)
    {
        bytes4[] sigs = type(this).signatures;
        uint mask = 0;
        for (var i = 0; i < sigs.length; i++)
            mask ^= uint(sigs[i]);
        return mask;
    }
}

contract Test is ERC165 {
  // ...
}

[chriseth]

@axic note that the type of this is always just the current contract (although all function calls are virtual). This means that interfaceID() will only contain the functions defined by ERC165 and not those additionally defined by Test.

[axic]

Right, we need templates then 😉

[axic]

In line with #1435 / #2473, .signatures should be renamed .selectors and a list of function types could be added, because then the selector can be retrieved on a function.

[axic]

I think it can be solved without templates too:

library ERC165 {
    function interfaceID(bytes4[] memory sigs) constant returns (uint)
    {
        uint mask = 0;
        for (var i = 0; i < sigs.length; i++)
            mask ^= uint(sigs[i]);
        return mask;
    }
}

contract Test {
  function interfaceID() constant returns (uint) {
    return ERC165.calculateInterfaceID(type(this).selectors);
  }
}

[chriseth]

Now that ERC165 is further towards standardisation - shall we add some kind of high level support for this?

[axic]

Right, we need templates then

An alternate solution to complete templates would be something like Ruby's mixins:

library ERC165 {
    mixin function interfaceID() constant returns (uint)
    {
        bytes4[] memory sigs = type(this).selectors;
        uint mask = 0;
        for (var i = 0; i < sigs.length; i++)
            mask ^= uint(sigs[i]);
        return mask;
    }
}

contract Test {
  mixin ERC165.interfaceID();
}

or

mixin ERC165 {
    function interfaceID() constant returns (uint)
    {
        bytes4[] memory sigs = type(this).selectors;
        uint mask = 0;
        for (var i = 0; i < sigs.length; i++)
            mask ^= uint(sigs[i]);
        return mask;
    }
}

contract Test {
  mixin ERC165;
}

Basically these are very restricted templates: no template parameters are supported, except that this always points to the type including it.