multiformats / js-multiformats

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

feat: allow CID by codec name where registered in multiformats #12

Closed

rvagg wants to merge 1 commit into multiformats:master from rvagg:rvagg/cid-string-code

+48 −10

Contributor

rvagg commented Jun 2, 2020

I found a pattern I kept reaching for was this so I didn't have to repeat magic numbers or their constants everywhere: new multiformats.CID(1, multiformats.get('codec-name').code, hash). This PR does that inside CID, restoring the ability to supply a string codec name where multiformats has that string->code mapping registered.

Also adds some more type checking.


        feat: allow CID by codec name where registered in multiformats

af139c7

rvagg reviewed

test/test-cid.js

  
            mapper = i => {

              const name = `new CID(${i}, 112, buffer)`

              test(name, () => testThrowAny(new CID(i, 112, hash)))

              test(name, () => testThrowAny(() => new CID(i, 112, hash)))

rvagg Jun 2, 2020

Author Contributor

wasn't being tested properly, I guess this is where the error message checking of throws() comes in handy

Member

mikeal commented Jun 8, 2020

This warrants some discussion.

I actually had this feature in mind when I started the implementation and then decided against it.

The reason I cut it was the same reason I fully deprecated the .codec property instead of making it work for codecs that were registered and throwing on ones that aren’t. Having the interface be more consistent left less room for errors and forces a full migration to the new interface.

The big shift people have to make with the new interface is thinking of a CID as a reference to something they may not know how to consume. Allowing the string name opens the door to people publishing libraries that don’t work unless you include codec support for something that you’re never actually encoding/decoding just because they wanted to use the string name to create CID instances.

Given that the Block API will still support string names (since it does require encode/decode) and will create CID’s for you, I don’t see a lot of uses for the string name in CID instantiation that we want to encourage and a lot that we’d want to discourage.

But there may be some usage I’m not considering here and am open to talking more about it.

Contributor Author

rvagg commented Jun 11, 2020

OK, so for anyone else reading this - we both agree that this piece of CID is a bit user-hostile and not ideal, but that also we hope that the new Block API will smooth this over and are making an assumption for now that the majority of work with CID will go through Block in some way.

So we'll shelve this for now and assess how the API ends up being used when we have all the pieces in place.

rvagg closed this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

You can’t perform that action at this time.