Feature SplitPayment contract

[abarmat]

Contract that allows distributing payments done to the registered payees based on their shares.

Expose a distributeFunds function callable by any of the payees to perform the distribution of funds.

Also a SplitPullPayment contract to use PullPayment to allow delayed withdrawal of funds by each payee.

[abarmat]

We can have an even slimmer SplitPayment contract by removing addPayeeMany and many of the getters that can be implemented by child classes.

[frangio]

I like this idea! I would do a bit of a refactoring, though, and remove the struct. I don't think it's necessary, it would be enough to replace payeeIndex and payees by the following:

mapping (address => uint256) shares;
address[] payees;

We could even do without the payees array if the API was directly like PullPayments. I mean, if instead of distributeFunds there was a function claim() which had to be called by each payee to take their share. This is a somewhat different implementation, though, so let me know what you think.

Agree with your comment on getters! Plus removing the struct would remove the need mostly.

I like the idea of an overrideable canUpdate, but there should be a safer default! This is the kind of situation that #366 is about, and I think the role based access control approach would be useful here.

[frangio]

By the way, Travis failed because we're running tests in Solidity 0.4.13. Unless there's a specific bug in that version that would affect this contract, can you change the pragma line to ^0.4.11 (like the rest of the repository) or at least ^0.4.13?

[abarmat]

Will do the changes, thank you for the feedback!

Let me thing about changing the interface to a claim() without distribute(). I didn't want to traverse the array of payees to do the allocation every time a payment is received to avoid extra gas costs to the sender. There might be a different way to do it.

[frangio]

Right, you can solve it without iterating over the array by keeping a variable with the amount of ether that has already been released, and a mapping with how much has been released for each participant.

I did something very similar in this TokenVesting contract (#412).

Hm, though I don't think this works if the list of participants is dynamic. Do you think it's necessary to be able to add participants after the contract is running?

[abarmat]

I updated the contract removing most of the getters and implemented it to resemble how the PullPayment contract works, with a claim() method for payees to take their cut. Please let me know your thoughts.

[frangio]

@abarmat Looks really great! Nice addition. :-)

Will merge after Travis finishes.