jbaylina / erc820 Goto Github PK

Readme says 0x820Afdf355177C099f0251e96A8e8B2974307381 is the central registry address, but there's no contract deployed there: https://etherscan.io/address/0x820Afdf355177C099f0251e96A8e8B2974307381

on the other hand, there's a deployed contract at the address hardcoded in
https://github.com/jbaylina/ERC820/blob/master/contracts/ERC820Client.sol
here it is:
https://etherscan.io/address/0x820c4597Fc3E4193282576750Ea4fcfe34DdF0a7
Is this the right one? It probably should go in the README

The function setInterfaceImplementer should fail if the interface is currently implemented as a ERC165 interface.

This is for backward compatibility. And also it is an implementation detail with how 820 cache currently works.

https://github.com/jbaylina/eip820/blob/master/contracts/EIP820Implementer.sol#L11
shouldn't we use constructor?

    function EIP820Implementer(address _registry) public {
      EIP820Registry eip820Registry = EIP820Registry(_registry);
    }

In the example ExampleImplementer.sol, the function canImplementInterfaceForAddress always returns the positive value of ERC820_ACCEPT_MAGIC. Shouldn't this be doing some check either internally in the contract or against the registry to see that the interface can be implemented?

Because the prepack hook runs the test script, which calls mocha --harmony, unless a dependent package is installed in an environment where mocha is installed globally, this package will fail to install.

https://github.com/jbaylina/eip820/blob/master/contracts/ExampleImplementer.sol#L5

pragma solidity ^0.4.18;

contract ExampleImplementer {
    function canImplementInterfaceForAddress(address addr, bytes32 interfaceHash) view public returns(bool) {
        return true;
    }
}

If I unlock the fallback function and provide some default behavior, then it would break those checks because of strange behavior by design in solidity if a method does not exist it will instead execute the fallback function, and if the fallback function does not raise an exception it will return 1 causing the check to pass.

The only solution that comes to my mind is to use some magic numbers. Maybe we should return uint which should be more than 0.

The current title is:
EIP 820 - Pseudo-introspaection using a registry contract

introspaection should be introspection

Update: the same typo is in the description field of package.json

Now when using erc820 contract with pragma solidity ^0.4.24 there are a lot of warnings. Would be nice if you could update.

the file ReferenceToken.sol in the package ipe777 imports EIP820Implementer.sol instead of the old name 'ERC820Implementer.sol` therefor the linking does not work.
The file should be renamed in this package to be able to compile eip777