Instead of using the term encapsulation, I would refer to visibility. I think encapsulation is used more specifically to refer to the restriction of direct access to state variables to functions within the same class (or contract in Solidity). Visibility, on the other hand, is a more commonly used term in Solidity, and refers to where both state variables and functions can be accessed from.
You are correct that it is the functions in the parent contract marked with public or internalvisibility which are available to be called from within the child/derived contract(s).
the base contract is the parent contract in the sense that its contents are inherited (/derived?) by children contracts
all base functions labeled internal or public are available to derived contracts
hierarchical inheritance describes the relationships between contracts deriving the data / functions / state variables / etc from certain others in a relationship that determines who inherits what and howâŚ
at least thatâs what i thought until i realized that the reading material is worded confoundingly such that i didnât understand this was a specific type of inheritance until i read the last paragraph where the author claims to have gone over the 4 listed types.
specifically hierarchical inheritance appears to be the inheritance of a base contract by two separate contracts.
from itâs name, you might think it referred to the diagram on multiple contracts, but afaict it doesnât⌠the fact that thereâs a code mistake in the polymorphism section only makes it harder to tell if the author made a mistake or intentionally worded things the way they did.
edit: after finding the same link as @Jackthelad i got a much clearer understanding of what is meant by the four inheritance styles. Essentially hierarchical inheritance is that in which two children are derived from one parent, useful in when the parentâs innards will be used in different contexts.
This is a fair point, and I agree that the article could be clearer regarding the definitions of the 4 different types of inheritance.
This is a good definition of hierarchical inheritance, except that, as well as two child contracts, it also describes inheritance structures where more than two (multiple) child contracts all derive from the same, single parent contract.
In terms of multiple inheritance, I donât think even the other article youâve mentioned defines this clearly. Basically, multiple inheritance is the opposite of hierarchical inheritance⌠where the same, single child contract inherits more than one (multiple) parent contracts e.g.
// Hierarchical inheritance
contract A { ... }
contract B is A { ... }
contract C is A { ... }
// Multiple inheritance
contract A { ... }
contract B { ... }
contract C is A, B { ... }
Iâd be interested to know what you think the code mistake is in the Polymorphism section⌠There is definitely an error in the code in the Interfaces section (see below), but I havenât come across any issues with the Polymorphism section.
(Note:âtheâvirtualâandâoverrideâkeywords would also now need to be used in the articleâs Contract Polymorphism code; but they werenât part of the syntax of the older Solidity version which it was originally written in.)
parent contract or base contract that is inherited by derived child contracts
all public and internal scoped
functions and state variables are available to derived contracts.
3.
single contract acts as a base contract for multiple derived contracts.
1-base Contract is the contract from which other (i.e child contracts) derived from
2-All public and internal functions are available for derived contracts
3-hierarchical inheritance means that one contract is the base contract for 2 or more other contracts
Which functions are available for derived contracts?
Internal and public functions and state variables.
What is hierarchical inheritance?
There is an order of inheritance, where for example A contract is a direct parent for B and C. And then D is child for B, C and A. There is a hierachy of contracts like that.
the code mistake was in the interface section, which i initially thought was part of the latter half of the article and called it the âpolymorphismâ section, but looking back on it, i see that the sections toward the end were somewhat independent but for for the first two.
thanks for the clarifications on hierarchical v multiple inhertances: totally makes sense!
With regard to inheritance in Solidity, the parent contract in a parent-child contract inheritance relationship is referred to as the base contract. Thus, the base contract is the contract from which the child/derived contract inherits.
Which functions are available for derived contracts?
Derived contracts can use public and internal scoped functions that are inherited from the parent contract.
What is hierarchical inheritance?
Hierarchical inheritance describes the situation when a parent contract has more than one child contract. Hierarchical inheritance is generally used when a specific functionality of a contract is to be used by many child contracts. It allows to reduce code redundancy as the functionality only needs to be written in code in the parent contract and all child contracts can use this functionality without having to rewrite the corresponding code.
What youâve described is a structure with both hierarchical and multiple inheritance. Letâs identify each one separately within your exampleâŚ
This part is hierarchical inheritance: where the same, single parent contract (A) is inherited by more than one (multiple) derived contracts (B and C), and these derived contracts do not inherit from each other.
This part is multiple inheritance (effectively the opposite of hierarchical inheritance): where the same, single derived contract (D) inherits more than one (multiple) parent contracts (B and C), and these parent contracts do not inherit from each other.
In fact, if your contract D doesnât explicity inherit A âŚ
contract A { ... }
contract B is A { ... }
contract C is A { ... }
contract D is B, C { ... }
⌠what you now have is 2 alternative linear inheritance relationships as well:
// A ---> B ---> D
// A ---> C ---> D
Contract D already inherits contracts B and C, and so it doesnât need to explicity inherit contract A, because it will inherit it implicitly via contracts B and C.
Let me know if anything is unclear, or if you have any questions
This isnât really true because, strictly speaking, redundant code is unnecessary code which doesnât need to be used. Instead, what inheritance does is reduce code duplication â which is in fact what you then, quite rightly, go on to say âŚ
Your answers are correct. I would remove the other answers youâve copy-and-pasted together with the questions, because one is wrong, and another isnât very accurate
Yes ⌠if the same, single base contract has 2 or more derived contracts.
What is the base contract?
Contract that other contracts inherit from, giving access to non private functions and state vars and the ability to override functions marked virtual.
Which functions are available for derived contracts?
Functions with internal and public modifiers.
The version of the function from the parent contract can be called via super.
The version of the function from any parent can be called using the parent contractâs name.
Also possible to call external functions via this
Uses an external contract call inefficient compared to internal calls
Can only access the externally exposed most derived version of the function
What is hierarchical inheritance?
Hierarchical inheritance is where multiple contracts share the same base class.
Correct ⌠but I would clarify that this refers to visibility. In Solidity the term modifier used on its own usually refers to a specific piece of code declared with the keyword modifier, which is applied to one or more function headers to validate inputs or restrict access according to the condition, or conditions, defined within the modifier.
This is correct if we are referring to an inherited function which has been overriden and also implemented in the derived contract we are making the call from. However, if there is only one implementation of the function in a base contract, and this is available in a derived contract via inheritance, the function can simply be called from within the derived contract using the function name as normal.
More specifically, super will call the implementation of the overridden function on the next most derived contract in the inheritance sequence. This is relevant when the child contract making the function call has more than one direct parent with an implementation of the same overriden function. Which of these ânext levelâ contracts is the next base contract in the inheritance sequence is determined by the order the contract names appear after the is keyword in the child contractâs header (the next base contract, or most derived contract, comes last).
True⌠but I canât see the point of this, especially if, as you say, itâs more inefficient. If we want to call a function in an inherited contract from within its derived contract, surely the most sensible thing to do is to not give that function external visibility in the first place. Instead, we should either make it public (so it can be called both externally and internally) or internal (if it doesnât need to be called externally). But, please do let me know if you can see a reason why we would want to give such a function external visibility, but then call it from the derived contract using this.
Let me know if you have any questions about any of my comments
1. What is the base contract?
The base contract is the parent contract that is getting inherited.
2. Which functions are available for derived contracts?
Public functions, internally scoped functions, and state variables are all available for derived contracts.
3. What is hierarchical inheritance?
This is when a parent contract is inherited by multiple children contracts, for example:
Parent Contract
------------
| contract A |
------------
/ \
| |
V V
------------ ------------
| contract B | | contract C |
------------ ------------
Child contract Child contract
Just to confirm ⌠as with functions, it is the state variables defined in the base contract with public or internal visibility which are available for derived contracts â state variables marked private are not available.
