A base contract is a contract that is inherited by other contracts, in other words, its state variables and functions get injected into other contracts. These other contracts are called derived contracts.
Derived contracts treat these state variables and functions like other state variables and functions of their own (except those with modifier private), which means they can call or change state variables and execute functions of the base contract.
2. Which functions are available for derived contracts?
Functions with modifiers such as public, external and internal are available for derived contracts.
Iâm not sure if functions and variables with modifier external can be called by derived contracts, because by definition after inheriting from a base contract, derived contracts treats all the things in the base contract as their own so that they are not external contracts anymore. It confuses me!
3. What is hierarchical inheritance?
When a base contract is inherited by two or more contracts, this type of inheritance is called hierarchical inheritance.
This part is correct and your answer should finish here.
Polymorphisim in Solidity doesnât have anything to do with different types of inheritance structure (e.g. hierarchical inheritance, multiple inheritance etc.)
And polymorphism has nothing to do interfaces.
Polymorphism, interfaces and abstract contracts in Solidity are more advanced topics, and what they are and involve, and how we use them, will gradually become clearer with further study and with more experience.
This is a very good effort at going deeper and getting to grips with the detail of what youâve learnt from the article
Your answers are correct except for how external visibility is affected by inheritanceâŚ
Only functions with public and internal visibility in the base contract will be available to be called from within the derived contract itself.
So, functions with public or internal visibility are inherited , as well as any functions in the base contract with external visibility. However, unlike public and internal functions, inheritedexternal functions wonât be available to be called from within the derived contract; when the derived contract is deployed, they will only be available to call externally e.g. from Remix, a Web3 client (such as the front-end interface of a dapp), or from an external (i.e. non-derived) contract.
The only functions which arenât inherited are those with private visibility.
State variables cannot have external visibility, so the state variables which are inherited, and which can be referenced, set or reassigned from within the derived contract, are those with public or internal visibility.
Hopefully this also clears up your confusion and resolves the uncertainties you mentioned surrounding external visibility. But do let me know if anything is still unclear, or if you have any further questions
Which functions are available for derived contracts?
ALL public and internal functions from the parent contract are available to the derived contracts.
What is hierarchical inheritance?
A type of inheritance where a single contract acts as a base contract for multiple derived contracts.
What is the base contract?
The parent contract is base contract.Solidity compiler copies the base contract bytecode into derived contract bytecode. The base contract is the contract that inherited. Which functions are available for derived contracts?
All public and internal scoped functions and state variables are available to derived contracts. What is hierarchical inheritance?
A single contract acts as a base contract for multiple derived contracts.
For example: contract A act as parent for child contract B and C.
Q2 Which functions are available for derived contracts
Not all of the functions in the base contract are available. Functions withâpublicâorâinternalâvisibility are available for derived contracts, but not those with private visibility.
A function in the base contract with external visibility will be inherited by a derived contract, but only to the extent that, when the derived contract is deployed, this function will be available to call externally e.g. from Remix, a web3 client (such as the front-end interface of a dapp), or from an external (i.e. non-derived) contract. However, unlike public and internal functions, an external function in the base contract is not available to be called from within the derived contract itself.
The only functions which arenât inherited are those with private visibility.
Let me know if anything is unclear, or if you have any questions
2. Which functions are available for derived contracts?
Public functions and internal modifiers only from the base contract it inherits features from. NOT those with private visibility.
3. What is hierarchical inheritance?
A single contract serves as the base contract for multiple derived contracts (aka a parent contract has many children)
Public and internal functions are available i.e. functions with public or internal visibility. Modifiers are not marked with a visibility keyword, and all modifiers in the base contract are available for its derived contract(s).
And just to complete the picture âŚ
As with functions, both public and internal state variables in the base contract are available for its derived contract(s), but not state variables marked private.
Any events declared in the base contract are available to be emitted in its derived contract(s).
A contract can inherit the variables, functions, modifiers, and events from another contract. That contract is called the âbaseâ contract.
all public and internal scoped functions and state variables are available to derived contracts.
A Hierarchical inheritance is like an org. chart. You have a âtopâ contract that a bunch of other contracts inherit from. You can have contract B, C, D etc that all inherit from contract A at the top of the hierarchy.
Correct ⌠except that it would be an organisation chart with only one âmanagerâ and their two or more âemployeesâ. Hierarchical inheritance only refers to the inheritance relationship between the same, single base contract, and two or more (multiple) derived contracts which inherit from it (i.e. two levels). You could have a larger inheritance structure with several hierarchical inheritance relationships integrated with each other over several levels. You could have âŚ
3 derived contracts (B, C and D) all inheriting from the same, single âtop-levelâ base contract (A). This would form one hierarchical inheritance relationship.
C is also the same, single base contract from which 2 derived contracts inherit (E and F). This would form another hierarchical inheritance relationship.
contract A { ... } // top level
contract B is A { ... } // middle level
contract C is A { ... } // middle level
contract D is A { ... } // middle level
contract E is C { ... } // bottom level
contract F is C { ... } // bottom level
This would then start to look more like the organisation chart that you mentioned as an analogy.
Would a variable, function, modifier or events from contract F in this example, be used in contract A even though its not the Base contract? Is contract C considered the base for E and F?
I also did not understand fully this part of the reading
The contract that is inherited is called the parent contract and the contract that inherits is called the child contract .
Similarly, the contract has a parent known as the derived class and the parent contract is known as a base contract
I understand that the parent contract, is the base contract, and the derived class is the âchildâ. Is this right?
âThe contract has a parent known as the derived classâ vs "the parent contract is known as a âbase contractâ is what im not following .
And when its compiled and deployed, its all just one smart contract with contracts inside on the blockchain with one blockchain adress?
No ⌠the âflow of inheritanceâ is in the other direction. So âŚ
Public and internal functions, public and internal state variables, all modifiers, all events and any constructors in A will be available in all three of its derived contracts (B, C and D), and in all of their derived contracts too (in our example E and F).
Also available in E and F will be the public and internal functions, public and internal state variables, all modifiers, all events and any constructors in C (E and Fâs parent/base contract), but not in B or D.
Only derived/child contracts can inherit from their own base/parent contract(s), from which they will also inherit any functionality which their base/parent contract(s) in turn inherit from any base/parent contract(s) of their own i.e. âgrandparentâ contract(s) ⌠so on and so on âup the chainâ of inheritance.
Yes ⌠contract C in our example is both a derived contract of A, and the base contract of E and F
Iâm not surprised by your confusion over part of the article, because there is an error in it. The fact that it confused you, and youâre questioning it, actually shows that you are really paying attention and thinking things through
Yes, thatâs correct.
This is where the error is. Contracts in Solidity operate in a similar way to classes in other object-oriented programming languages, and therefore the following are alternative names for the same thing:
parent contract = base contract = base class
child contract = derived contract = derived class
So, this sentence in the article should, instead, read something like âŚ
The child contract is known as a derived contract, or the derived class; and the parent contract is known as a base contract, or the base class.
If you deploy Bank, then itâs just one smart contract called Bank, deployed on the blockchain at a single address. There are no âcontracts insideâ Bank. When Bank is compiled, all of the functionality that it inherits from Destroyable and Ownable is automatically included, and the result is a single set of bytecode, which is then deployed at a single Ethereum address on the Ethereum blockchain.
You could also deploy Destroyable, although there wouldnât be much point, as it only really has any purpose when inherited and compiled together with a derived contract which will utilise its specialised contract-destruction functionality. However, if you did, then it would also just be one smart contract called Destroyable, deployed on the blockchain at a single address. Itâs compiled bytecode would include all of the functionality that it inherits from Ownable, but nothing from Bank.
And if you were to just deploy Ownable, then the deployed bytecode would have only been compiled from Ownable, and nothing else.
I hope that makes things clearer. Just let me know if you have any further questions
The contract that is inherited is the parent contract
Which functions are available for derived contracts?
.All public and internal functions and state variables are available for derived contracts.
What is hierarchical inheritance?
Hierarchical inheritance is again similar to simple inheritance. Here, however, a single contract acts as a base contract for multiple derived contracts.
