20

Yes. The internal modifer means that the function can only be called within the contract itself and any derived contracts. private functions are not available in derived contracts. From the docs: internal: Those functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it), without usingĀ ...


19

The internal modifier can be better compared with protected in object-oriented programming languages. Internal functions of the contract C are visible to the code running at the current address (i.e. the current contract instance) but also to contracts derived from C. Note that due to the architecture of the EVM, visibility is something that can be strictly ...


13

Last question first: overloading concept applies to Solidity but, as for other programming languages supporting overloading functions, i.e. C++, they are not related to each other in any way. Functions with same name but different parameters are identified by different signatures, so they are actually different functions. If ContractA defines doSomething(), ...


12

No, you do not need to call the parent constructor yourself unless you need to pass arguments to it (detailed examples here). As far as addresses go, the solidity file specified above is basically like a class specification. You will decide what actually gets an address at the time of instantiation. Most likely, when you instantiate contract B somehow, ...


10

It's an "Abstract" a.k.a. "Interface" contract. It's used to define the interface, meaning the functions that exist, their exact names and inputs/outputs while being silent about how they work internally. The idea is to use inheritance to create a compliant implementation - a contract with the exact same functions implemented. You go about it like this....


9

Yes, you are correct. Something I noticed which is worth keeping an eye on is that both modifiers of 'parent' contracts as well as any functions are overwritten by inheritance even when using 'super'. For example, calling test(0) on B passes and returns 10 (not 5 as one may be led to believe), but fails on contract A. pragma solidity ^0.4.15; contract A {...


9

Enums defined inside a contract are by default accessible from other contracts. In Producer you can use the expressions: Supplier.State.inactive Supplier.State.active Supplier.State.kaput Your code is not working because public state variables behave like functions from the perspective of other contracts. Try replacing this line: require(_supplier.status =...


8

I did a few test and seems like the order you use to extend the classes it matter. Given this example: pragma solidity 0.4.21; contract Ownable { event OwnableE(uint); function Ownable() public { emit OwnableE(1); } } contract TimedCrowdsale { event TimedCrowdsaleE(uint); function TimedCrowdsale() public { emit ...


7

We have two approaches: Inheritance contract Parent { string w; function Set(string _w) public { w = _w; } function Greet(string name) internal view returns(string) { return string(abi.encodePacked(w, name)); } } contract Child is Parent { function Get() public view returns(string) { return Greet("Bob"); ...


6

In the first instance your contract is inheriting from the TestLibrary contract, and therefore you can perform the operation with increment(_base) or super.increment(_base). Additionally, if the function is public (which it will be by default), then that function is viewable and usable on your contract when it is deployed. In the second instance, you are ...


6

In Solidity you specify base constructor arguments in two ways (according to http://solidity.readthedocs.io/en/latest/contracts.html#arguments-for-base-constructors): The first way to do it is more convenient if the constructor argument is a constant and defines the behaviour of the contract or describes it. The second way has to be used if the ...


5

Contract standard Token is derived from Token. This concept is called inheritance. Solidity as a contract-oriented programming language allows inheritance that enables new contracts to take on the properties of existing contracts. Functions can be overridden by another function with the same name and the same number/types of inputs. Here the transfer ...


5

In a 1-1 comparison Composition is more expensive to deploy, and execute. That said, if you need to deploy many instances, you could use the Library pattern and use composition in that way. Libraries can lower deployment costs if you're going to be deploying many copies of the same code. If you imagine deploying 100 copies of the same code, you may only ...


4

The is keyword (not "Is") is used for inheritance in Solidity. The closest thing to a list of keywords in the Solidity docs is this section which has: Global Variables Function Visibility Specifiers Modifiers Reserved Keywords Language Grammar


4

Using Browser-Solidity, I compiled and deployed contract B with the following code: contract A { function() { throw; } } contract B is A() { } I executed a sendTransaction(...) to B (fallback) and the Out Of Gas error was thrown. So the answer is Yes.


4

I do not have a full answer but I will share what I found out. I used Browser Solidity to compile contracts, and used Etherscan's disassembler to help me out with the result. When I compiled contract A {} in Browser Solidity, I looked at "Assembly" (you need to "Toggle Details"). It shows: .code PUSH 60 contract A {\n} // Some Stuff... JUMPI ...


4

After research I found: With multiple inheritance, there is an issue caused by the Diamond Problem. Solidity solves this problem like Python. Here are two links describing this problem in detail: https://docs.python.org/2/tutorial/classes.html#instance-objects https://www.python.org/download/releases/2.3/mro/ So, the order of inheritance is important in ...


4

A little clean-up. You need Test2 defined before Test1 inherits from it, so the order is reversed. Add public to functions to avoid warning about default visibility. Constructor in Test1 has nothing else to do, so removed. Since it inherits from Test2, the Test2 constructor will run. In case it is not clear, Test1 will have a state variable called ...


4

From the perspective of gas usage, composition will be more expensive, mainly because you will have more CALL opcodes and more contracts instantiations. See Appendix G Fee Schedules (G_call, G_create, G_callvalue, ...) in the yellow paper -> https://ethereum.github.io/yellowpaper/paper.pdf


4

The 'exploit' no longer applies to solc v0.6, since then the compiler generates an error when there's an ambiguous call. As the author says solc v0.5 uses C3 linearization to determine the order in which functions will be called. In the cited example the C3 linearization order is [Bank, MultiAdmin, TempAdmin, Admin]. When funct() is called the first ...


3

It's just too tangled up to sort it out in a few moves. The main thing seems to be the way you're mixing up interfaces and inheritance. You don't want to use inheritance to merely talk to another contract or even to make another contract from a template. I took your three concepts and renamed them to "Storage", "Client" and "ClientFactory". Following is a "...


3

Your contract 'MyToken' is a child of 'StandardToken', it inherits the 'transfer' function. You do not need to define 'transfer' because you can already use it. If you want to override the 'transfer' function, you can read about it here.


3

Well you say it yourself, you're not calling aString, but super.printMe(). Have a deeper explanation of superhere: The super keyword in Solidity gives access to the immediate parent contract from which the current contract is derived. You are explicitly calling the parent contract Hello, in which aString is 'Hello, world.' Look at the difference if in ...


3

You need to interface deployed Storage contract functions. pragma solidity ^0.4.8; contract Storage { function getEntityCount() public constant returns(uint entityCount); } contract Access1{ address storgeContractAddress = "0xcd53170a761f024a0441eb15e2f995ae94634c06"; Storage storage; function Access1(){ storage = Storage(...


3

This returns b then increments a (and fixes the initialization of b): contract test2 is test{ uint b; function test2() { b = a++; } function show() returns(uint){ b = a++; return b; } }


3

This is touched on a bit here: https://solidity.readthedocs.io/en/v0.4.21/contracts.html#visibility-and-getters, but essentially what you're saying is correct. <address>.<function>() (e.g. this.whoIsSender()) sends a message to the contract at that address. This is an external call, and msg.sender is the address of the account that made the call....


3

I believe this exact scenario is covered by the Solidity: Inheritance > Arguments for Base Constructors Here is the example they give: pragma solidity ^0.4.22; contract Base { uint x; constructor(uint _x) public { x = _x; } } contract Derived2 is Base { constructor(uint _y) Base(_y * _y) public {} } So for you, it would look something like ...


3

You do not need to explicitly deploy any contracts you inherit from, or any contracts that are deployed during the deployment of another contract. For instance, if you have: contract A is B { } Contract B does not need to be deployed at all. Additionally, if you have: contract A is B { C cInstance = new C(); } Then C will be deployed automatically ...


3

Borrowing the notation from C3 linearization on Wikipedia, and keeping in mind that Solidity reverses the typical ordering ("You have to list the direct base contracts in the order from 'most base-like' to 'most derived'. Note that this order is different from the one used in Python."): L(AC) := [AC] + merge(L(C), L(A), [C, A]) = [AC] + merge([C], [A]...


3

You could override an internal function that implements the check pragma solidity 0.4.24; contract Base { bool public active; modifier canSetMetadata() { require(canSetMetadata_()); _; } function canSetMetadata_() internal view returns (bool) { return (active == false); } } contract BaseWithMetadataControl is ...


Only top voted, non community-wiki answers of a minimum length are eligible