Add contract calls for total contribution balances #110

Merged
bumi merged 5 commits from feature/contribution-balances into master 2019-04-23 12:47:51 +00:00
bumi commented 2019-04-19 11:07:46 +00:00 (Migrated from github.com)

Those methods return the total kredits amounts of contributions.

Those methods return the total kredits amounts of contributions.
raucao (Migrated from github.com) requested changes 2019-04-19 11:25:07 +00:00
raucao (Migrated from github.com) left a comment

Unfortunately, I still cannot test anything locally, because the scripts still hang for me (which looks like ipfs can't get the data, but could be something else, too).

Yay, after waiting a while, it finally got the docs this time!

<del>Unfortunately, I still cannot test anything locally, because the scripts still hang for me (which looks like ipfs can't get the data, but could be something else, too).</del> Yay, after waiting a while, it finally got the docs this time!
raucao (Migrated from github.com) commented 2019-04-19 11:23:23 +00:00

I think this is mixing up "count" and "balance". If it's returning the number of contributions, then it should be "count", but if it's returning the amount of kredits that have been created, then it should be something different. "Balance" also doesn't apply in this case, because that word means an amount per person/account.

Thus, I'd propose to call it something like totalKreditsAmount or totalKreditsSupply totalKreditsEarned or simply totalKredits.

I think this is mixing up "count" and "balance". If it's returning the number of contributions, then it should be "count", but if it's returning the amount of kredits that have been created, then it should be something different. "Balance" also doesn't apply in this case, because that word means an amount per person/account. Thus, I'd propose to call it something like `totalKreditsAmount` or `totalKreditsSupply` `totalKreditsEarned` or simply `totalKredits`.
bumi (Migrated from github.com) reviewed 2019-04-19 11:41:05 +00:00
bumi (Migrated from github.com) commented 2019-04-19 11:41:05 +00:00

yeah, naming sucks.. especially because the standard method names are misleading.

totalKredits does not work imo because we might sell kredits tokens - thus the tokens could be more than the ones eared.

from your ideas I think totalKreditsEarned works best I think?

yeah, naming sucks.. especially because the standard method names are misleading. `totalKredits` does not work imo because we might sell kredits tokens - thus the tokens could be more than the ones eared. from your ideas I think `totalKreditsEarned` works best I think?
bumi (Migrated from github.com) reviewed 2019-04-19 11:44:17 +00:00
bumi (Migrated from github.com) commented 2019-04-19 11:44:17 +00:00

that then would be totalKreditsEarned and contributorTotalKreditsEarned ?

that then would be `totalKreditsEarned` and `contributorTotalKreditsEarned` ?
raucao (Migrated from github.com) reviewed 2019-04-19 11:53:45 +00:00
raucao (Migrated from github.com) commented 2019-04-19 11:53:45 +00:00

What's contributorTotalKreditsEarned? Maybe you mean Contributor.totalKreditsEarned?

What's `contributorTotalKreditsEarned`? Maybe you mean `Contributor.totalKreditsEarned`?
bumi (Migrated from github.com) reviewed 2019-04-19 11:57:28 +00:00
bumi (Migrated from github.com) commented 2019-04-19 11:57:28 +00:00

if we were not in a smart contract world then maybe.
but that is a view method on a contract.

we can define a totalKreditsEarned on the Contributor wrapper class.

if we were not in a smart contract world then maybe. but that is a view method on a contract. we can define a `totalKreditsEarned` on the Contributor wrapper class.
raucao (Migrated from github.com) reviewed 2019-04-19 12:02:49 +00:00
raucao (Migrated from github.com) commented 2019-04-19 12:02:49 +00:00

Sorry, but I still don't understand what it returns in Contribution then.

Sorry, but I still don't understand what it returns in `Contribution` then.
bumi (Migrated from github.com) reviewed 2019-04-19 12:13:56 +00:00
bumi (Migrated from github.com) commented 2019-04-19 12:13:56 +00:00

the total numbers of kredits for that contributor.
it counts the kredits of all the contributor's contributions.

the total numbers of kredits for that contributor. it counts the kredits of all the contributor's contributions.
raucao (Migrated from github.com) reviewed 2019-04-19 12:23:45 +00:00
raucao (Migrated from github.com) commented 2019-04-19 12:23:44 +00:00

OK, thanks. I think the helper function should be in the contributor contract, not the wrapper, but it would at least be necessary as a function in the contribution contract still. Reason being that the contributor contract can then deliver toplists sorted by kredits earned and such. Same for list of core team members etc., saving the client from having to load the entirety of the data every time.

OK, thanks. I think the helper function should be in the contributor contract, not the wrapper, but it would at least be necessary as a function in the contribution contract still. Reason being that the contributor contract can then deliver toplists sorted by kredits earned and such. Same for list of core team members etc., saving the client from having to load the entirety of the data every time.
raucao (Migrated from github.com) approved these changes 2019-04-19 12:26:54 +00:00
raucao commented 2019-04-19 12:27:09 +00:00 (Migrated from github.com)

Missing kredits label btw.

Missing kredits label btw.
bumi (Migrated from github.com) reviewed 2019-04-19 12:42:55 +00:00
bumi (Migrated from github.com) commented 2019-04-19 12:42:55 +00:00

try to implement it, you will see that this not possible as you imagine.
also it would again increase the coupling of the two different contracts.

In a normal object oriented world I'd agree, but not in that contract world which also makes it hard to read and work with data. (I also think the smart contracts are not made for that and we would need to do such things rather on a different level).

try to implement it, you will see that this not possible as you imagine. also it would again increase the coupling of the two different contracts. In a normal object oriented world I'd agree, but not in that contract world which also makes it hard to read and work with data. (I also think the smart contracts are not made for that and we would need to do such things rather on a different level).
raucao (Migrated from github.com) reviewed 2019-04-19 12:45:39 +00:00
raucao (Migrated from github.com) commented 2019-04-19 12:45:39 +00:00

If it's easy to do like this in the contribution contract, then I don't see why the contributor contract cannot use those functions, as it does for other functions as well. I'm not talking about object orientation at all. Not sure where that's coming from.

But that's not a discussion for this PR anyway.

If it's easy to do like this in the contribution contract, then I don't see why the contributor contract cannot use those functions, as it does for other functions as well. I'm not talking about object orientation at all. Not sure where that's coming from. But that's not a discussion for this PR anyway.
bumi (Migrated from github.com) reviewed 2019-04-19 12:46:40 +00:00
bumi (Migrated from github.com) commented 2019-04-19 12:46:40 +00:00

PRs welcome :)

PRs welcome :)
Sign in to join this conversation.
No description provided.