Conversation
EIPS/draft_token_validation.md
Outdated
| Created: 2018-02-14 | ||
|
|
||
| ## Simple Summary | ||
| A protocol for services providing financial transaction validation. |
There was a problem hiding this comment.
should include the word token in the summary.
EIPS/draft_token_validation.md
Outdated
|
|
||
| EIP: <to be assigned> | ||
| Title: Token Validation | ||
| Author: Tom Carchrae<[email protected]>, Gleb Naumenko<[email protected]>, Brooklyn Zelenka<[email protected]> |
There was a problem hiding this comment.
the author order is backwards! i appreciate the alphabetical ordering, but you've done most of the work @expede
| @@ -0,0 +1,181 @@ | |||
| ## Preamble | |||
There was a problem hiding this comment.
not sure draft should be part of the filename
EIPS/draft_token_validation.md
Outdated
| interface TokenValidator { | ||
| function check( | ||
| address _token, | ||
| address _user |
There was a problem hiding this comment.
🤔 Is _address too general, though? I get that it may represent an autonomous contract in addition to human users. Perhaps _subject or _toCheck? (ie: the one being checked?)
EIPS/draft_token_validation.md
Outdated
|
|
||
| > parameters | ||
| > * `token`: the token under review | ||
| > * `user`: the user to check |
EIPS/draft_token_validation.md
Outdated
|
|
||
| ##### check/2 | ||
|
|
||
| `function check(address token, address user) public returns (uint8 resultCode)` |
There was a problem hiding this comment.
keep the args the same as the interface (eg, prefix vars with _)
|
|
||
| ##### check/4 | ||
|
|
||
| `function check(address token, address from, address to, uint256 amount) public returns (uint8 resultCode)` |
There was a problem hiding this comment.
perhaps it would be nicer to give these each unique names. eg, checkTransfer and checkAddress
not dead set on this, just wondering if we could make them more specific/meaningful (but not too meaningful)
There was a problem hiding this comment.
Yeah, fair point. It might be the Elixir/Erlang in me (which has a very similar name overloading system). It reads as implicit to me, but my background is very weird compared to most people 😛 check(address) and check(to, from, amount) seem pretty clear, but it also doesn't hurt to have some "duplication" (if it can even really be called that).
Thinking out loud, since all that the ABI knows about is the types, we really have:
check(address, address)check(address, address, address, uint8)
Giving them longer/specific names would prevent namespace conflicts with like...
check(contractA, contractB) { return contractA == contractB; }check(exchange, tokenA, tokenB, proposedConversionRate)
🤔
There was a problem hiding this comment.
i like the elegance/terseness of check but i am not sure how it all plays with solidity.
it seems that you're saved from namespace inheritance clashes http://solidity.readthedocs.io/en/develop/contracts.html#overload-resolution-and-argument-matching
If there is not exactly one candidate, resolution fails.
but joy!
Return parameters are not taken into account for overload resolution.
There was a problem hiding this comment.
Well, we both like check. We could toss it out to the community and see what they think. I'm not married to check(...) 🤷🏻♀️
EIPS/draft_token_validation.md
Outdated
|
|
||
| ```solidity | ||
| function approve(address spender, uint amount) public returns (bool success) { | ||
| if(validator.check(this, msg.sender, spender, amount) == !okStatusCode) { |
There was a problem hiding this comment.
not a fan of == !, you could make it != but even better, no negation just put L150 in the block if check(....) == okStatusCode
There was a problem hiding this comment.
and use else to make the flow clear. return is an evil goto
There was a problem hiding this comment.
returnis an evilgoto
I agree in this case. Are you not a fan of guard statements generally, or just here?
There was a problem hiding this comment.
well, if truly a guard, wouldn't you use require()
?
but yeah, overall, not a big fan when, say, commenting out the return statement would cause the function to execute the else - just use else. more explicit, less bug chance, etc.
There was a problem hiding this comment.
Well, I might not want it to blow up, but yes, indeed way more idiomatic in Solidity 👌🏻
EIPS/draft_token_validation.md
Outdated
| specify a transfer amount or recipient. This is intended for general checks, | ||
| such as checking roles (admin, owner, &c), or if a user is on a simple whitelist. | ||
| You may still use `check/4`, but passing dummy data just to satisfy a function contract | ||
| is generally frowned upon. |
There was a problem hiding this comment.
sentence doesn't parse - i get what you are saying (you can use dummy values and just have one check) but it doesn't come through.
maybe better to keep the explanation direct and prescriptive rather than "hey you can do this but we say don't because it sucks" - we could have things like that in a different section (or later paragraph).
|
@carchrae Thanks for the feedback. Fixed! Once you get back from frolicking in the snow (and no earlier), gimme a ✅ if you're happy with the changes 🙆🏻♀️ |
EIPS/token_validation.md
Outdated
|
|
||
| > parameters | ||
| > * `_token`: the token under review | ||
| > * `_user`: the user to check |
There was a problem hiding this comment.
nit; _user isn't the same as _address above.
btw, i kind of agree with the comment you made (notified on slack, but not on github anymore) around _address being nebulous. perhaps _to would be a better descriptor? not certain on that though, but it makes it somewhat consistent with check/4 and i think it might make sense. but not sure.
There was a problem hiding this comment.
I'm not totally certain about _to, since the arities are more than optional params. It could also be _from or something else. "Bob has surpassed his trade volume limit" or "Alice is a known criminal".
I think that this is still in line with Solidity, since even with the same arity we could have foo(uint8 _x), foo(uint8[] _xs) and foo(mapping(address => bool) _convenience). Of course as a best practice all foos should have some semantic similarity. An implementer would be able to rename a field to better suit their domain, too , since Solidity it only cares about the types. check(address _company, address _shareholder) { ... }.
EIPS/token_validation.md
Outdated
| This event MUST be fired on return from a call to a `TokenValidator.check/2`. | ||
|
|
||
| > parameters | ||
| > * `user`: the user to check |
There was a problem hiding this comment.
again, re nit above. should keep interface/events using same terms
The proposal that we've been working on. Should be ready for submission soon. Last round of feedback!
We've done a lot of discussion in person. It's all still fair game, from title to specifics.