9

You don't try to deploy the abstract interface contract IUser. contract User is IUser {} You deploy (migrate) User. Other contracts can use the abstraction to understand the interface to User. User is IUser protects you from certain kinds of developer errors such as failing to define a function in the interface. Hope it helps. Some clarification to ...


6

You can cast the contract to an address type with msg.sender != address(tokenContract)


6

approveAndCall for exchanges The approveAndCall / receiveApproval pattern is an old pattern used by exchanges to perform an atomic transfer of funds in a single step. This old method has mostly since been superseded by other standards, however it's still quite common in usage. The idea is that an exchange wants to do 2 things. Buy tokens for you. Take ...


5

The one without _data doesn't send any data when it calls the other contract. (It sends a zero-length byte sequence.) The one with _data does.


5

This might be of some help. http://hypernephelist.com/2016/06/21/a-simple-smart-contract-ui-web3.html There are frameworks that conveniently deal with dependencies, so a lot of us prefer to go that route. A very high-level overview if what's described in the link, is you will need to: load the web3 API get the ABI (a JSON helper that describes the ...


4

When the developer makes a contract that inherits the interface, he/she is committing to implementing the functions defined in the interface. Failing to do so will result in undefined functions in the contract. Since that will not do, the contract will be rejected by the EVM. From a quality assurance perspective, a refusal to deploy contract with an ...


3

According to my experience in the following code https://gist.github.com/anonymous/c23f944b139a76693abbae261ad577b8 it is enough implementing those ones you are using. In the example: /// ---- dataStorage interface contract dataStorage { function getBalanceOf(address _account) constant returns (uint256 balance); function setBalanceOf(address ...


3

Just cast to address: if (address(sampleInterface) != address(0)) {


3

First, as pointed by @goodvibration, you don't need to recast BAT_TOKEN_ADDRESS to the ERC20 interface since you already did it when assigning its value. Second, your BATSend function should check whether the tokens transfer was successful or not since transfer returns a boolean (true if the transfer was successful, false otherwise), like that : ...


2

You don't need the full ABI, just the interface for the functions you want to call. For example, the following code will get the totalSupply of the BAT token without having to know anything except for the address where it resides and the function signature we are calling: contract ERC20 { function totalSupply() constant returns (uint totalSupply); } ...


2

An interface explains to the compiler what functions are available to be called on an external contract without requiring the full source code of that contract to be imported. In this case, the kittyContract has been deployed completely separately to this zombie contract. So on the ethereum blockchain this kittyContract exists and now this new, unrelated ...


2

They're referring https://github.com/ethereum/EIPs/issues/165 This has been further developed in https://github.com/ethereum/EIPs/issues/881 The specification there says: We define the interface identifier as the XOR of all function selectors in the interface. Hence, you have to do something like this: supportedInterfaces[this.ifc_method_1.selector ^ ....


2

There is an EIP67 that proposes Sending ETH ethereum:<address>[?from=<sender_address>][?value=<ethamount>][?gas=<suggestedGas>] Sending ERC20 tokens ethereum:<address>[?from=<sender_address>][?value=<ethamount>][?gas=<suggestedGas>][?mode=erc20__transfer]


2

If you wish your token to be ERC20 compliant you have to have the required functions with the required signatures. That's the whole point of the standard. However, that leaves you with two other options: 1) Add more functions and/or contract variables. You can add whatever functions you wish with whatever signatures and functionality you wish as long as ...


2

This is where interfaces come in. That's great, because ERC-20 is actually an interface! I'll give you an example below. As you can see, the TokenSwapper doesn't even need to know about TokenA and TokenB, just that they implement the ERC20 interface. Oh and before you start developing, you should first make yourself familiar with the basics of the ERC20 ...


2

One contract cannot simultaneously implement ERC-20 and ERC-721. You must design your system so that those are separate contracts (deployed at separate addresses). Yes, you can have a ERC-721 contract make calls to an ERC-20 contracts. There is nothing that makes that a problem.


2

There are two separate reasons you would want to separate your logic into more than one contracts / libraries / etc. 1- Modularity, ease of use, ease of maintenance. If you forgo the usage of libraries or inheritance from other contracts your code go be a huge file with dozens of functions, which is hard to maintain, read, reuse, etc. 2- Implementing ...


2

To my knowledge, there is no plan to allow this. The whole idea of interfaces is to ensure that implementations do conform to the interface. Non-compliant contracts can and do cause serious problems at the level of interactions with others, where "others" means other contracts, wallets and exchanges that expect a certain kind of behavior. Possibly ...


2

Some concepts: An abstract contract implements only some of the declared functions, while leaving the others unimplemented. When choosing to use an abstract contract, it is typically because we have a group of contracts with a common functionality, but with additional unique functionality in each contract. So we implement this common functionality in the ...


2

Actually, transferFrom is payable in EIP 721. From https://eips.ethereum.org/EIPS/eip-721: function transferFrom(address _from, address _to, uint256 _tokenId) external payable; So it's not a modification at all. It's already part of the interface. If the code you're using doesn't have payable there, you can simply add it.


1

It's a convention in Solidity to declare local variables names with the first letter "_". I personally prefer to do the same for internal functions. For instance: function _decrementBalance(uint _index, uint _value) internal { uint oldBalance = accountBalances[_index]; uint newBalance = oldBalance.sub(_value); accountBalances[_index] = ...


1

Using underscores in front of variable names is simply due to convention. Some languages encourage using underscore for private variables so it's easy to distinguish between private and public variables. Solidity does the same - using underscores before private (inside a function) variables makes them easy to spot. I'm not sure what you mean with avoiding ...


1

A fair bit of fiddling for readability and style. pragma solidity 0.4.25; contract Interface { function call() public pure returns (string); function isInterface() public pure returns(bool); } contract Interfacing { Interface daContract; constructor(address theContract) public { daContract = Interface(theContract); ...


1

There is no way to do this in a stable version of solidity, but possible in experimental pragma experimental ABIEncoderV2; interface CupInteraface { struct S { bytes32 s; } function get(bytes32 cup) external returns (S memory); } contract Cup is CupInteraface { mapping(bytes32 => S) private _cups; constructor(bytes32 cup) ...


1

You are not forced to create and abstract contract to do an implementation. Solidity is not a strongly OOP language, even if something is derived from OOP (interface, inheritance, abstract contracts). So said abstract contracts will give you another level of abstraction and the main reason to use it is to be sure that who implements the contract will follow ...


1

Mostly, it's for two main reasons: 1) Functions aren't variables and they are not interchangeable 2) Functions support a lot more things than variables do. Actually variables don't support any functionality, just their (convenience) getters. Functions and variables behave quite differently. You have to implement the interface's functions, which literally ...


1

From the ERC-721 draft standard, take note of the code comments in the interface provided. Specifically, for the safeTransferFrom function without the 4th parameter: /// @dev This works identically to the other function with an extra data parameter, /// except this function just sets data to "" So your three-parameter function should do exactly the same ...


1

Other answers return false positives for contracts with no fallback function defined. Assembly code seems like the only way to go.. combined Tjaden Hess's answer with How do I construct a call to another contract using inline assembly? Answer: function testIsSafe(address _addr) private returns (bool _isSafe) { bytes32 sig = bytes4(keccak256("...


1

It's called function overloading, where two functions have the same name but take in different arguments, you can read more about it here: http://solidity.readthedocs.io/en/develop/contracts.html


1

address ckAddress = 0x06012c8cf97BEaD5deAe237070F9587f8E7A266d; KittyInterface kittyContract = KittyInterface(ckAddress); // this initialization is what I don't get That line isn't doing any sort of "initalization." It's just casting the address. It means that kittyContract is now a contract of type KittyInterface, and that when you call functions on that ...


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