-
Notifications
You must be signed in to change notification settings - Fork 52
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
Proposal: add some method e.g. .toLink(): CID
on CID object
#185
Comments
Yeah, ok, sounds reasonable I think. So you'd presumably also have an implementation on a |
Usually these objects already have a CID (e.g. because they were loaded from block store or a car file), so often they can just return CID.
There are might be other thins in the future which need to compute CID and consequently would not be able to return CID sync. However I don't think that should be a concern for this proposal, for such use cases one may define some other interface e.g. interface AsyncLinkable {
toLink(): Promise<CID>
} And then in the functions that want to support this define input param as That said, I personally don't like taking things that could potentially run async computations. I much rather prefer to be more clear on who's responsibility it is to run such a computation as in it's either callers responsibility to precompute those things or it is callees (in which case later should probably in more control of what kind of CIDs are created hashing alg etc...). |
By making it sync, you're narrowing down the places where this can be used and potentially putting a lot of complexity onto the user. We already have a strong theme of I guess it's up to you, and we can adjust later, it just might be an awkward adjustment. Re
Do you mean just adding a |
Assuming you meant |
Alternatively we could just remove Lines 41 to 42 in 3d4ae50
That way other things could just implement |
What other implications might there be for removing that |
More things having
|
Yeah, so to be clear that I'm grokking your concern here - if we remove the
|
Rational
Often times when working with partial DAGs we find ourselves with mix of materialized nodes for local blocks and links external blocks. When working in such a domain I often find myself wishing:
Both sides of the call would be happier if you could pass something "linkable" instead, that way callers could pass arbitrary nodes (as long as they are linkable) and callee could just use a link without having to inspect arguments.
Proposal
Linkable
:Linkable
interface.That way arbitrary objects could implement
Linkable
interface which would allow them to be used everywhereLinkable
is accepted. Functions that typically wantCID
s could also start accepting more generalLinkable
s and there for allow passing arbitrary object that could be linked.Alternative
For what it's worth we already have something along these lines in form of
asCID
property. However it is a private property so TS complains about it. We could make it non private and achieve same goal by implementingasCID
property on desired nodes.The text was updated successfully, but these errors were encountered: