FEATURE: Additional mapping support methods about vyper

[vbuterin]

This would more than double gas costs. It would require the map to keep track of an array of all keys and keep it updated, so that you can go through the keys when needed. It would also substantially increase code complexity. In that specific case, you can always just manually make a funders_list array and push to it. IMO a better approach for these kinds of problems is the "poke-based" paradigm, where a user needs to poke the contract to refund themselves; this more clearly aligns gas incentives and keeps per-transaction gas requirements down.

[fubuloubu]

I agree with the poke-based paradigm, that is mostly what I was using when I writing examples as it is the cheapeast and puts the gas costs in the right place. In some examples it is more useful (e.g. refunding in the crowdunding example) or unavoidable (e.g. calculating any sort of global statistics over members in the map).

Does gas get consumed to read data? My understanding was that gas only actually got consumed when writing out data (hence the constant decorator). I agree it would be a substantial enough increase to gas cost for that datatype that it shouldn't be the default for a map, I don't see how overall gas costs would increase that substantially though. I think this suggestion has enough utility that it should be considered as a future feature implemented in some easier-to-use way than the current method of the range method for iterating an array.

If you think this idea has limited utility (i.e. the need to call transactions for all the members of a map in a clear way or compute global statistics is not common), then I will close this issue.

[fubuloubu]

Another thought, can additional code used to track membership in the mapping (e.g. funders_list) be added as a compiler extension such that when the proposed feature is requested, a standard method to track the information is employed behind the scenes, which prevents easy mistakes from having to manually track entries (e.g. forgetting to add to the array when multiple methods update the mapping)?

This way, it is optional but standardized and only increases gas costs when necessary.

Updated example:

funders: public(wei_value[address])
# Set public getter on mapping to return list of (k, v) pairs

@constant
def is_funder(_addr: address) -> bool:
    return _addr in self.funders.keys() # Evaluates to list of tracked keys

# Note: self.balance should be the same number, but ignoring that for our example
@constant
def amt_raised() -> wei_value:
    sum: wei_value
    # self.funders.values() evaluates to [self.funders[k] for k in self.funders.keys()]
    for value in self.funders.values():
         sum += value
    return sum # or return sum(self.funders.values()) if sum() exists

# Not enough money was raised! Refund a person
def refund(_funder: address):
    assert block.timestamp >= self.deadline and self.balance < self.goal
    assert is_funder(_funder)
    send(funder, self.funders[_funder])
    del self.funders[_funder] # Resets value in self.funders AND removes from tracking list

Call above using [c.refund(f) for (f, _) in c.get_funders()] which avoids gas estimate problems and refunds everyone all at once since the list of addresses is accessed as @constant (no gas) and the transactions are processed sequentially by the caller externally (e.g. all N transactions can be created at once externally instead of trying to put an upper bound on the estimate of the range() function in the contract, putting control in the user's hands to decide how much gas s/he can spend at once)

[jacqueswww]

@fubuloubu can this be closed?

[fubuloubu]

Yeah, doesn't make sense to think about mappings this way, plus we have other better features/proposals (a la iterators, etc.) that will take care of the proposed here.