You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the get function fails if any property keys contain a '/'.
eg: for the object { 'this/will/be/funny': false } if a block is made out of it, block.get('this/will/be/funny') will not work. I think that this library should change the interface to be get( ['this/will/be/funny'] ) instead of a string, to make this unambiguous, but I do appreciate this issue may be too pedantic to warrant a change.
As a curious piece of trivia, linux paths cannot have the '/' in directory names not because of any config or other configurable parameter, but because it remains to this day hard coded into the kernel. JS objects on the other hand....
The text was updated successfully, but these errors were encountered:
This is one of those areas where the behaviour is not clearly defined, but it's also difficult to handle. Generally you're advised to avoid such property names because even if we had an elegant means of addressing it here, it's going to appear higher up the stack.
But that doesn't really help when go-ipfs wants to turn ipfs dag get /path/to/thing because it still has to perform a transformation of that path string to be segments by splitting on /.
If you want to propose an API addition that gives us a clear array-of-segments approach then we could probably work to get that in and give people an avenue to work around the / namespace conflicts; but it's not going to be a universal solution unfortunately.
Thank you for this library - I appreciate that this problem is very rare.
In this file:
js-multiformats/src/block.js
Line 129 in 7db4b72
eg: for the object
{ 'this/will/be/funny': false }
if a block is made out of it,block.get('this/will/be/funny')
will not work. I think that this library should change the interface to beget( ['this/will/be/funny'] )
instead of a string, to make this unambiguous, but I do appreciate this issue may be too pedantic to warrant a change.As a curious piece of trivia, linux paths cannot have the '/' in directory names not because of any config or other configurable parameter, but because it remains to this day hard coded into the kernel. JS objects on the other hand....
The text was updated successfully, but these errors were encountered: