Benefits of using abstract contracts

[VoR0220]

I think there needs to be added documentation on the benefits of utilizing abstract contract functions...Is there not a cheapening of gas that comes with using an abstract contract? I may be wrong but I think it does. Either way...the documentation doesn't really give a reason why I would want to use an abstract contract or when I would want to...this could be improved.

[axic]

I don't think it has any relation to gas costs.

Abstract contracts are a counterpart of the JSON ABI definition in Solidity.

[redsquirrel]

The main benefits of an abstract contract are:

• Providing a place to define a contract interface, which is useful for self-documentation as well as extensibility.
• Giving us the ability to implement most of a contract, but leave some methods abstract, facilitating patterns like template method and more generally removing code duplication.

[VoR0220]

^this should be documented.

[R1j1t]

Abstract contract can also be used to remove cyclic dependencies. Explanation by @tcoulter in issue #135

[tjayrush]

In C++, one can create a pure virtual interface that forces uses inheriting from a class to implement certain functions. Is there a similar idea in Solidity? If yes, this should be documented. If no, what happens to a smart contract that presents an interface in an abstract contract, but then does not implement that interface in the derived contract? This should be documented.

Also--I know it is possible to derive a smart contract from two different abstract contracts (token plus safe math, for example). What happens in the case of a function signature conflict? This should be documented as well.

[redsquirrel]

@tjayrush Solidity's interfaces are documented here: https://solidity.readthedocs.io/en/develop/contracts.html#interfaces

Solidity's inherited signature collision is documented here: https://solidity.readthedocs.io/en/develop/contracts.html#inheriting-different-kinds-of-members-of-the-same-name

[o0ragman0o]

I'm unfortunately finding little efficiency with Interfaces. Abstract getters aren't recognised as implemented by public state variables. So I end up just using the abstract contract model with public state declared there rather than using private state with explicit getters.

[tjayrush]

@o0ragman0o In C++, you would have to implement a separate getter in the derived class, so that makes a bit of sense to me. I guess the point you're making is due to the automatic nature of setters/getters? It seems to me that, without the data in the abstract class, there wouldn't be an automatic generation of setters/getters. But in any case, to get back to the issue, this behaviour should be documented as well.

A summary of above issues so far:

benefits

• self-documentation
• easier upgradability
• template method
• lessening code duplication
• removal of cyclic dependancies

questions

• does it support forcing implementations?
• how are conflicts resolved (already documented)

watch outs

• getters/setters in abstract class not inherited.

[androlo]

It can be forced at compile time, if that's what you mean by forcing.

Btw. ERC-20 tokens is a good example of an actual interface that people are using. Look at that standard: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md

Notice how it not only states that the contract should contain this and that, but also offers some actual interface contract that can be used by developers. Solidity also provides an interface in the standard contracts (Token.sol in the std folder).