-
Notifications
You must be signed in to change notification settings - Fork 324
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
BlockId should not have a default and passing a chain tip should be an Option
#1107
Comments
I agree with you, |
Hey @SpaghettiSats. Getting the chain tip is clearly very useful, it just doesn't do anything by being in the trait at the moment. In the examples or your app you will almost always be dealing with a concrete impl of There is a way the library could make use of That's the direction I'd take if we want to keep it. Please have a go at that if you feel so inspired. |
Thanks for the explanation. Now I understand. I will try to do so! |
See discussion: #1116 (comment) |
It does not make sense for a BlockId to have a default. We use the
Default
to semantically mean a null block. e.g.I think these should just take an
Option
for the tip since that's the rusty way of communicating null. When it'sNone
it should just be assumed that nothing is in the chain.Maybe the tip should take an argument that is
Option<B> where B: Into<BlockId>
to avoid themap
.On a related note
ChainOracle
hasget_chain_tip
despite this not being used anywhere. I'd say we should remove it. Perhaps we will want this later but we can just make a new trait for that likeGetChainTip
.The text was updated successfully, but these errors were encountered: