[Ethereum] How to create Interface to read Struct in mapping

interfacessoliditystruct

There are 2 contracts A and B.

A has a mapping which returns Struct:

mapping (bytes32 => Cup) public cups;

How can we read the cups mapping in contract B?

Following code doesn't work for sure:

interface CupsInteraface {
    function cups(bytes32 cup) external returns (Struct);
}

Best Answer

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) public {
        _cups[cup] = S(cup);
    }

    function get(bytes32 cup) public returns (S memory) {
        return _cups[cup];
    }
}

Related Solutions

[Ethereum] How to return a mapping type

You need to break the interface down into smaller chunks. In practice, you'll want to extend the internal storage pattern a little, I think.

Iterable mapping comes to mind. You keep lists of keys to mappings in arrays. Something like this:

  struct VoterStruct {
    address voterAddress;
    uint256 tokensBought;
    mapping (bytes32 => uint256) tokensUsed;
    bytes32[] tokenIndex; // a list of mapping keys that exist for the voter
  }

  mapping (address => VoterStruct) public voterStructs;

Then you can expose functions that allow iterating over lists while the contract returns one set of values at a time. Very sketchy to inspire some ideas:

// client can discover how may tokens are in the list for one voter
function getVoterTokenCount(address voter) returns(uint tokenCount) {
    return voterStructs[voter].tokenIndex.length;}

// client can discover the tokenId for a voter in a given row
function getVoterTokenAtIndex(address voter, uint index) returns(bytes32 tokenId) {
    return voterStructs[voter].tokenIndex[index];}

// client can discover token used by voter and tokenId
function getVoterTokenUsed(address voter, bytes32 tokenId) returns(uint tokensUsed) {
    return voterStructs[voter].tokensUsed[tokenId];}

// append keys to the list as you go
function insertVoterToken(address voter, bytes32 tokenId) returns(bool success) {
    voterStructs[voter].tokenIndex.push(tokenId);
    return true;}

Hope I didn't flub the syntax. It might be possible to sketch out the contract a little more. Would need a general description of what it's going to do. When I use this pattern, I always add some rules to ensure there are no duplicate keys, and so on.

Anyway, possibly the hints will inspire some ideas.

Hope it helps.

[Ethereum] (Sub) contract vs. library vs. struct vs. Interface

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 parent/child contracts has more to do with the logic of your code. For example, for a bidding app, you could have one contract that stores all the bids going on with their corresponding data (bidders, winning bid, etc) OR, you could create Bid contracts that each one holds the logic on their own, and then a parent contract that keeps a reference to every bid contract that gets created.

Each approach has it's own pros and cons and it really depends on what the requirements are for your application.

Best Answer

Related Solutions

[Ethereum] How to return a mapping type

[Ethereum] (Sub) contract vs. library vs. struct vs. Interface

Related Topic