ERC-1900: rename typeHash to identifier, add links to related ERCs

EIPS/eip-1900.md

@@ -9,7 +9,6 @@ category: ERC
 created: 2019-03-28
 ---
 
-
 ## Simple Summary
 
 The EVM and related languages such as Solidity need consensus on an extensible Type System in order to further evolve into the Singleton Operating System (The World Computer).
@@ -23,7 +22,7 @@ We are proposing a decentralized Type System for Ethereum, to introduce data def
 
 In order to build a network of interoperable protocols on Ethereum, we need data standardization, to ensure a smooth flow of on-chain information. Off-chain, the Type Registry will allow a better analysis of blockchain data (e.g. for blockchain explorers) and creation of smart contract development tools for easily using existing types in a new smart contract.
 
-However, this is only the first phase. As defined in this document and in the future proposals that will be based on this one, we are proposing something more: a decentralized Type System with Data Storage. This means each Type can have a Storage Contract that stores data entries that are of that type. These data entries can originate from different protocols or developers and are aggregated within the same smart contract. In addition, developers can create libraries of `pure` functions that know how to interact and modify the data entries. This will effectively create the base for a general functional programming system on Ethereum, where developers can use previously created building blocks.
+However, this is only the first phase. As defined in this document and in the future proposals that will be based on this one, we are proposing something more: a decentralized Type System with Data Storage - [ERC-2158](https://github.com/ethereum/EIPs/pull/2158). In addition, developers can create libraries of `pure` functions that know how to interact and modify the data entries - [dType Functions Extension](https://github.com/ethereum/EIPs/issues/1921). This will effectively create the base for a general functional programming system on Ethereum, where developers can use previously created building blocks.
 
 To summarize:
 
@@ -99,7 +98,7 @@ library myTokenLib {
 Type metadata will be registered on-chain, in the dType registry contract. This consists of:
 - `name` - the type's name, as it would be used in Solidity; it can be stored as a `string` or encoded as `bytes`. The name can have a human-readable part and a version number.
 - `typeChoice` - used for storing additional ABI data that differentiate how types are handled on and off chain. It is defined as an `enum` with the following options: `BaseType`, `PayableFunction`, `StateFunction`, `ViewFunction`, `PureFunction`, `Event`
-- `contractAddress` - the Ethereum `address` of the `TypeRootContract`. For this proposal, we can consider the Type Library address as the `TypeRootContract`. Future EIPs will make it more flexible and propose additional TypeStorage contracts that will modify the scope of `contractAddress`.
+- `contractAddress` - the Ethereum `address` of the `TypeRootContract`. For this proposal, we can consider the Type Library address as the `TypeRootContract`. Future EIPs will make it more flexible and propose additional TypeStorage contracts that will modify the scope of `contractAddress` - [ERC-2158](https://github.com/ethereum/EIPs/pull/2158).
 - `source` - a `bytes32` Swarm hash where the source code of the type library and contracts can be found; in future EIPs, where dType will be extended to support other languages (e.g. JavaScript, Rust), the file identified by the Swarm hash will contain the type definitions in that language.
 - `types` - metadata for subtypes: the first depth level internal components. This is an array of objects (`structs`), with the following fields:
   - `name` - the subtype name, of type `string`, similar to the above `name` definition
@@ -148,6 +147,7 @@ Composed types can be further composed:
 ```
 {
   "contractAddress": "0x91E3737f15e9b182EdD44D45d943cF248b3a3BF9",
+  "typeChoice": 0,
   "source": <a SWARM hash for type source code files>,
   "name": "myToken",
   "types": [
@@ -189,13 +189,13 @@ struct dType {
 
 ```
 
-For storage, we propose a pattern which isolates the type metadata from additional storage-specific data and allows CRUD operations on records. This pattern has been described in detail here: https://medium.com/robhitchens/solidity-crud-part-1-824ffa69509a.
+For storage, we propose a pattern which isolates the type metadata from additional storage-specific data and allows CRUD operations on records.
 
 ```
-// key: typeHash
+// key: identifier
 mapping(bytes32 => Type) public typeStruct;
 
-// array of typeHashes
+// array of identifiers
 bytes32[] public typeIndex;
 
 struct Type {
@@ -204,31 +204,32 @@ struct Type {
 }
 ```
 
-Note that we are proposing to define the type's primary identifier, `typeHash`, as `keccak256(abi.encodePacked(name))`. If the system is extended to other programming languages, we can define `typeHash` as `keccak256(abi.encodePacked(language, name))`.
+Note that we are proposing to define the type's primary identifier, `identifier`, as `keccak256(abi.encodePacked(name))`. If the system is extended to other programming languages, we can define `identifier` as `keccak256(abi.encodePacked(language, name))`.
 Initially, single word English names can be disallowed, avoiding name squatting.
 
 
 The dType registry interface is:
 
 ```
+import './dTypeLib.sol';
 interface dType {
-    event LogNew(bytes32 indexed hash, uint256 indexed index);
-    event LogUpdate(bytes32 indexed hash, uint256 indexed index);
-    event LogRemove(bytes32 indexed hash, uint256 indexed index);
+    event LogNew(bytes32 indexed identifier, uint256 indexed index);
+    event LogUpdate(bytes32 indexed identifier, uint256 indexed index);
+    event LogRemove(bytes32 indexed identifier, uint256 indexed index);
 
-    function insert(dTypeLib.dType memory data) external returns (bytes32 dataHash)
+    function insert(dTypeLib.dType calldata data) external returns (bytes32 identifier);
 
-    function remove(bytes32 typeHash) external returns(uint256 index)
+    function remove(bytes32 identifier) external returns(uint256 index);
 
-    function count() external view returns(uint256 counter)
+    function count() external view returns(uint256 counter);
 
-    function getTypeHash(string memory name) pure external returns (bytes32 typeHash)
+    function getTypeIdentifier(string memory name) pure external returns (bytes32 identifier);
 
-    function getByHash(bytes32 typeHash) view external returns(Type memory dtype)
+    function getByIdentifier(bytes32 identifier) view external returns(dTypeLib.dType memory dtype);
 
-    function get(string memory name) view external returns(Type memory dtype)
+    function get(string memory name) view external returns(dTypeLib.dType memory dtype);
 
-    function isType(bytes32 typeHash) view external returns(bool isIndeed)
+    function isRegistered(bytes32 identifier) view external returns(bool registered);
 }
 ```
 
@@ -251,7 +252,7 @@ The effort of having consensus on new types being added or removing unused ones
 
 After the basis of such a system is specified, we can move forward to building a static type checking system at compile time, based on the type definitions and rules stored in the dType registry.
 
-The Type Library must express the behavior strictly pertinent to its defined type. Storage patterns for type instances will be covered in a future ERC and must abide by the same rule. Additional behavior, required by various project's business logic can be added later, through libraries containing functions that handle the respective type. These can also be registered in dType, but will be detailed in a future ERC.
+The Type Library must express the behavior strictly pertinent to its defined type. Additional behavior, required by various project's business logic can be added later, through libraries containing functions that handle the respective type. These can also be registered in dType, but will be detailed in a future ERC.
 
 This is an approach that will separate definitions from stored data and behavior, allowing for easier and more secure fine-grained upgrades.