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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add
SetSubnetOwner
toChain
interface #2031add
SetSubnetOwner
toChain
interface #2031Changes from 24 commits
e11c476
2d66725
e83458d
8f63ba4
a6364db
895f0c7
5faf60b
d65e483
9b5ad9e
32ce3b8
192e2f1
2a94bdf
7d59881
f43dc90
5e8c152
07b74c6
645013f
e0890d4
897ac65
c374609
54e6387
b3edbeb
60836b7
f1c86ca
bef73ab
28803b6
3a9bfaf
da17042
2154de3
4f0124a
4436795
85afb53
c6d03d2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
feel free to ignore this comment: It's consistent w/ the rest of the code but I personally don't think we need comments 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 agree, we'll keep it for now but I'll probably make a follow-up cleaning up the comments
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 understand this wrapper is just to be able to use fx.Owner in a sizedCache without recalculating the size every time.
The wrapper feels like a band-aid to me. I'd add a size method to fx.Owner interface to let ever owner be used in a sizedCache. Also fx.Owner implementation may be able to calculate statically their serialized size, without need to actually serialize data
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 didn't think it made sense to have a
Bytes()
like method forfx.Owner
since the normal usage is passing it into another struct. This is a special case since we're explicitly tracking the owners separately so I'd like to keep it contained 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.
I would add a
Size()
method to fx.Owner, not aBytes()
one.I don't see why this is a special case. I can imagine other clients, possibly in other VMs may be interested in caching
fx.Owner
s. So by having Size() method defined we'd avoid them the wrapper thing.Also I'd like to avoid the wrapper in the P-chain. state is already pretty complex, I really don't see why we should add ad-hoc machinery to handle objects serialization and caching. We should push all of those machinery to the object themselves and slim down P-chain state.
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 prefer implementing this wrapper as it's currently done for now and if we find that we keep needing this in other places we can consider implementing it on the
fx
package. I like package being able to define their own abstractions and keeping the interface as minimal as possibleThere 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 feels a bit weird (to be performing a write on the read)... But I think it's ok
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 thought loop variables in go were created once and the value was updated with each iteration, so I thought we wouldn't need these copies here. I think it's safe to remove these lines but i could be wrong.
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.
You are correct, it is safe to remove but I'd like to keep them since it's easier to understand that this is correct
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 the linter is going to yell at us because we are passing references to these values into functions. While it is true that those functions don't hold a reference to them... it feels like this is more clearly correct (until go 1.22)