mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
Merge 9c454b3538
into 72671d6c88
This commit is contained in:
commit
10ebe7ee89
@ -15,7 +15,7 @@ arguments to be stored in the transaction's log - a special data structure
|
||||
in the blockchain. These logs are associated with the address of the contract that emitted them,
|
||||
are incorporated into the blockchain, and stay there as long as a block is
|
||||
accessible (forever as of now, but this might
|
||||
change with Serenity). The Log and its event data is not accessible from within
|
||||
change in the future). The Log and its event data is not accessible from within
|
||||
contracts (not even from the contract that created them).
|
||||
|
||||
It is possible to request a Merkle proof for logs, so if
|
||||
|
@ -590,9 +590,11 @@ One area where inheritance linearization is especially important and perhaps not
|
||||
Inheriting Different Kinds of Members of the Same Name
|
||||
======================================================
|
||||
|
||||
It is an error when any of the following pairs in a contract have the same name due to inheritance:
|
||||
- a function and a modifier
|
||||
- a function and an event
|
||||
- an event and a modifier
|
||||
The only situations where, due to inheritance, a contract may contain multiple definitions sharing
|
||||
the same name are:
|
||||
|
||||
As an exception, a state variable getter can override an external function.
|
||||
- Overloading of functions.
|
||||
- Overriding of virtual functions.
|
||||
- Overriding of external virtual functions by state variable getters.
|
||||
- Overriding of virtual modifiers.
|
||||
- Overloading of events.
|
||||
|
@ -233,7 +233,7 @@ Yes:
|
||||
bytes32[] options
|
||||
);
|
||||
|
||||
LongAndLotsOfArgs(
|
||||
emit LongAndLotsOfArgs(
|
||||
sender,
|
||||
recipient,
|
||||
publicKey,
|
||||
@ -251,7 +251,7 @@ No:
|
||||
uint256 amount,
|
||||
bytes32[] options);
|
||||
|
||||
LongAndLotsOfArgs(sender,
|
||||
emit LongAndLotsOfArgs(sender,
|
||||
recipient,
|
||||
publicKey,
|
||||
amount,
|
||||
@ -1045,13 +1045,15 @@ No:
|
||||
Order of Layout
|
||||
***************
|
||||
|
||||
Layout contract elements in the following order:
|
||||
Contract elements should be laid out in the following order:
|
||||
|
||||
1. Pragma statements
|
||||
2. Import statements
|
||||
3. Interfaces
|
||||
4. Libraries
|
||||
5. Contracts
|
||||
3. Events
|
||||
4. Errors
|
||||
5. Interfaces
|
||||
6. Libraries
|
||||
7. Contracts
|
||||
|
||||
Inside each contract, library or interface, use the following order:
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user