-
Notifications
You must be signed in to change notification settings - Fork 47
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
Tweak parameters of NewPrefix functions. #51
Conversation
@Stebalien do you think we could get this change in ASAP? Right now it doesn't look like these functions are used. Once they become used this change will become more difficult. |
So, aren't we planning on replacing these functions with a |
That is, I'd rather deprecate and remove these functions and move to that than to break things. |
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.
At the moment, this'll only break a few tests and I agree it's more correct. However, I'd rather move forward with the Format constructor (complete with options) and simply deprecate these, if possible.
Possible way forward:
Basically, changing the signature will be the same amount of work as deprecating and removing. |
Not merging this P.R. is partly blocking #50. A grep of the entire source tree found that these functions are used in only one place outside of go-cid in #52 will take awhile to review and get in, this is a very simple change. My plan was to get #40/#50 in before #52. As far work, all that needs to be done is to just merge this P.R. We don't need to GX publish just yet. If this gets GX published before #52 gets in fixing the signature in the one place is not a lot of work compared to the updating all the places that use |
That'll still break anyone calling Also, there are other users:
If an interface is broken and we'll want to break it eventually, I'm usually all for breaking it sooner rather than later. However, given that we want to simply replace these functions, I'd rather leave them as-is (they still work, even if they allow invalid states) and then replace and deprecate them. |
Found a bunch of non-PL projects that rely on this.
Closing in favor of #53. |
I don't think these two functions are really used yet, so this shouldn't break anything.
NewPrefixV0
doesn't take any parameters, since there is only one possible legal combination.NewCidV1
is expanded to also take the multihash length. Even though the length 99% of the time will be-1
it still makes sense to require it. This gives the function the opportunity to convert the length value of-1
to the default length. The callee of the function is already likely to have the length value and needs to do something with it. With out being able to pass it in the most logical think to do would be to set it afterwards, for example:which doesn't allow NewPrefix to set the value to the default length.
Closes #49.