Solidity tutorial 5 "Enums ~ Multiple Inheritance and Linearization"

Enums

Enums are another way to create a user-defined type in Solidity.
They are explicitly convertible to and from all integer types but implicit conversion is not allowed.
The variable of enum type can be declared as constant.

contract test { 
    enum ActionChoices { 
        GoLeft, GoRight, GoStraight, SitStill 
        }

  ActionChoices choices;
  ActionChoices constant defaultChoice = ActionChoices.GoStraight;

    function setGoStraight() {
        choices = ActionChoices.GoStraight;
        }

    function getChoice() returns (uint) {
        return uint(choices);  
        }

    function getDefaultChoice() returns (uint) { 
        return uint(defaultChoice);
        }

Interfacing with other Contracts

There are two ways to interface with other contracts
Either call a method of a contract whose address is known or create a new contract.

Both uses are shown in the example below.
Note that (obviously) the source code of a contract to be created needs to be known, which means that it has to come before the contract that creates it.
And cyclic dependencies are not possible since the bytecode of the new contract is actually contained in the bytecode of the creating contract.

  • contract OwnedToken
    TokenCreator is a contract type that is defined below:
    It is fine to reference it as long as it is not used to create a new contract.
TokenCreator creator;
address owner;
bytes32 name;

function OwnedToken(bytes32 _name) {
      address nameReg = 0x72ba7d8e73fe8eb666ea66babc8116a41bfb10e2;
}

nameReg.call("register", _name);
owner = msg.sender;

We do an explicit type conversion from address to TokenCreator and assume that the type of the calling contract is TokenCreator, there is no real way to check.

creator = TokenCreator(msg.sender);
name = _name
function changeName(bytes32 newName) {
   // Only the creator can alter the name -- contracts are explicitly convertible to addresses.
}
    if (msg.sender == address(creator)) {
        name = newName;
        }

  function transfer(address newOwner) {
      // Only the current owner can transfer the token.
  }
 if (msg.sender != owner) return;

We also want to ask the creator if the transfer is fine.
Note that this calls a function of the contract defined below.

If the call fails (e.g. due to out-of-gas), the execution here stops immediately (the ability to catch this will be added later).

if (creator.isTokenTransferOK(owner, newOwner) {
owner = newOwner;}

contract TokenCreator {
    function createToken(bytes32 name) 
    returns (address tokenAddress) {
        //Create a new Token contract and return its address.
         return address(new OwnedToken(name))  
         }
  function changeName(address tokenAddress, bytes32 name) {
        // We need an explicit type conversion because contract types are not part of the ABI.  
    OwnedToken token = OwnedToken(tokenAddress);
    token.changeName(name  
    }

  function isTokenTransferOK(address currentOwner, address newOwner) returns (bool ok) {
      // Check some arbitrary condition.
    address tokenAddress = msg.sender;
    return (sha3(newOwner) & 0xff) == (bytes20(tokenAddress) & 0xff)
    }

Constructor Arguments:

A Solidity contract expects constructor arguments after the end of the contract data itself.
This means that you pass the arguments to a contract by putting them after the compiled bytes as returned by the compiler in the usual ABI format.

Contract Inheritance

Solidity supports multiple inheritances by copying code including polymorphism.
Details are given in the following example.

contract owned {
    function owned() { owner = msg.sender; }
    address owner;
}

// Use "is" to derive from another contract. Derived contracts can access all members
// including private functions and storage variables.
contract mortal is owned {
    function kill() { if (msg.sender == owner) suicide(owner); }
}

// These are only provided to make the interface known to the compiler.
contract Config { 
    function lookup(uint id) returns (address adr) {} 
    }

contract NameReg { function register(bytes32 name) {} function unregister() {} }

// Multiple inheritance is possible. Note that "owned" is also a base class of
// "mortal", yet there is only a single instance of "owned" (as for virtual
// inheritance in C++).
contract named is owned, mortal {
    function named(bytes32 name) {
        address ConfigAddress = 0xd5f9d8d94886e70b06e474c3fb14fd43e2f23970;
        NameReg(Config(ConfigAddress).lookup(1)).register(name);
    }

// Functions can be overridden, both local and message-based function calls take
// these overrides into account.
    function kill() {
        if (msg.sender == owner) {
            address ConfigAddress = 0xd5f9d8d94886e70b06e474c3fb14fd43e2f23970;
            NameReg(Config(ConfigAddress).lookup(1)).unregister();
// It is still possible to call a specific overridden function. 
            mortal.kill();
        }
    }
}

// If a constructor takes an argument, it needs to be provided in the header.
contract PriceFeed is owned, mortal, named("GoldFeed") {
   function updateInfo(uint newInfo) {
      if (msg.sender == owner) info = newInfo;
   }

   function get() constant returns(uint r) { return info; }

   uint info;
}

Note that above, we call mortal.kill() to "forward" the destruction request. The way this is done is problematic, as seen in the following example:
contract mortal is owned {
    function kill() { if (msg.sender == owner) suicide(owner); }
}

contract Base1 is mortal {
    function kill() { /* do cleanup 1 */ mortal.kill(); }
}

contract Base2 is mortal {
    function kill() { /* do cleanup 2 */ mortal.kill(); }
}

contract Final is Base1, Base2 {
}

A call to Final.kill() will call Base2.kill as the most derived override, but this function will bypass Base1.kill, basically because it does not even know about Base1.

contract mortal is owned {
    function kill() { if (msg.sender == owner) suicide(owner); }
}

contract Base1 is mortal {
    function kill() { /* do cleanup 1 */ super.kill(); }
}

contract Base2 is mortal {
    function kill() { /* do cleanup 2 */ super.kill(); }
}

contract Final is Base1, Base2 {
}

If Base1 calls a function of super, it does not simply call this function on one of its base contracts, it rather calls this function on the next base contract in the final inheritance graph, so it will call Base2.kill().

Note that the actual function that is called when using super is not known in the context of the class where it is used, although its type is known.
This is similar for ordinary virtual method lookup.

Multiple Inheritance and Linearization

Languages that allow multiple inheritance have to deal with several problems, one of them being the Diamond Problem.

Solidity follows the path of Python and uses C3 Linearization to force a specific order in the DAG of base classes.
This results in the desirable property of monotonicity but disallows some inheritance graphs. Especially, the order in which the base classes are given in the is directive is important.

In the following code, Solidity will give the error "Linearization of inheritance graph impossible".

contract X {}
contract A is X {}
contract C is A, X {}

The reason for this is that C requests X to override A (by specifying A, X in this order), but A itself requests to override X, which is a contradiction that cannot be resolved.

A simple rule to remember is to specify the base classes in the order from "most base-like" to "most derived".

Next Lesson

Summary of Lessons

AUTHOR

READ NEXT

Boostlog is an online community for developers
who want to share ideas and grow each other.

Delete an article

Deleted articles are gone forever. Are you sure?