This repository has been archived by the owner on Aug 2, 2021. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
swarm, swap: pass chequebook address at start-up #1718
swarm, swap: pass chequebook address at start-up #1718
Changes from 5 commits
9f3b920
2ce640e
596fffa
6b0b0ab
fae4caf
ff854d1
1a8d089
53d1398
9d7f449
274c1c5
81338c9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since
err
is implicitly initialized, you can justreturn
hereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get rid of named paramater.
@mortelli our code policy is to write return arguments explicitly even if we have named return params
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to keep the initialization of
err
in the function initialization, because otherwise, I can't doObviously, if it is a strict policy not to have named return parameters, I can do that, but in this case, I need 2 extra lines of code (to initialize a variable for the
contractInstance
, and assign this tos.contract
). This was how I did it initially, but @holisticode asked me to do it in a one-liner.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is fine. I also like sometimes that vars are initialised,
the policy is more about not having bare
return
-s if the function has return values.it makes things more readable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't change this, due to Swarm code policy. Please tell me if you disagree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused as to what the path parameter does.
Is this to satisfy a Interface?, or is it something that is not being used.
And if this is the case what would be the use of such path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused about this as well. Actually removed it before when I was doing refactoring, but when I reverted the refactoring, I also left this one in now.
Tagging @holisticode , maybe he knows. I would personally remove it, as it does not seem to have a purpose
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the tests pass after removing this parameter, i say let's go ahead with this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be nicer to extract this into a setup function. too much swap specific logic is here and makes swarm.go harder to read.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then you can also eliminate the else-s as you just return
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't we call
verifyContract
instead ofValidateCode
directly?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one. Indeed that would be better!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With hindsight, I would actually propose to not change it to
ValidateCode
. The reason is thatverifyContract
is used as part ofprotocol.go
to verify the chequebook contract of the counterparty. @ralph-pichler is doing research on how to make this check more elaborate.In the instance where I am using the check, however, we actually only have to verify the
deployedBytecode
, so I would prefer to use the lower level call (cswap.validateCode
) over the higher-level call (swap.verifyContract
) which might add more checks in the future.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while i see your point, i think changes like these should be made in an atomic manner—i'm not a fan of leaving code around due to "just in case"- or "for later use"-type of situations.
right now, all
verifyContract
does is callValidateCode
. even their comments are very similar:i would either:
ValidateCode
and always callverifyContract
directlyValidateCode
for consistency's sakei will not consider this a blocker for approval, though 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose for option 2.
Meant I also had to rewrite some tests:
TestVerifyContract
=>TestValidateCode
TestVerifyWrongContract
=>TestValideWrongCode
I don't find this particularly nice, as the unit tests in
swap
are now actually testing functionality ofcontracts/swap
. If we would like to change this, however, there is a need to create a new testSuite incontracts/swap
.I refrain from doing this at the moment but will put it on the agenda for the next sync meeting to hear to the opinion of team members.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you for putting this down for discussion.
i'm all for a new test suite if the situation calls for it 👍