Expose ToJson and FromJson methods
#885
Comments
|
You mean as exported Go APIs, since currently |
Right, I need them in |
JounQin
changed the title
toJson and FromJson methodsToJson and FromJson methods
|
A notice for WASM, we'd better not use |
|
At some point I do want to remove the dependency on reflect, but right now I want to stick with |
I'm not sure how to. 😅
Sorry I'm very new bee for go lang. Could you help to give me some advices? |
|
Yes, I indeed mean not using these APIs if you cannot use reflect. So you probably shouldn't wait for them right now :) |
|
I should also add that we should look into why our use of reflect wouldn't work. I am fairly sure that TinyGo does support part of reflect, for example. |
|
Yep, partly supported. And we should also consider the final bundle size for WASM, that why we use |
|
Right, size matters. That's a reason to not use libraries like easyjson, in fact, because they are often many times bigger than |
|
I tried but failed with native
|
|
Looks like it is only blocked on
Right, though easyjson uses code generation, so I'm fairly sure that the output size suffers because of it. In the future, I can remove the use of reflection by swapping encoding/json with the token encoder and decoder in https://github.com/go-json-experiment/json. I don't want to do that right away, as I want to get "from JSON" working well first. |
|
Great to hear! |
|
Thinking outloud: this API should not be in the syntax package, because we don't want to require a JSON library to be able to parse shell. |
What do you think should we do in |
|
Nothing has to change there. It's just that instead of having the API like |
Create a new package with docs, copy the code, and expose the API.
The following changes were made to the API:
* Name the main APIs Encode and Decode.
* Added options structs, to give us flexibility in the future.
* The "pretty" option is now an Indent string, like encoding/json.
Note that we now require "Type" keys to come first in each object.
This is not required right now, nor is it enforced by our decoder yet,
but it will be necessary to implement a performant decoder.
This is because we can only decode fields once we know the type;
if the "Type" key comes later, we must decode twice or buffer tokens.
The typed JSON encoding also changes slightly: since we want Encode and
Decode to work on syntax.Node rather than syntax.File, the root node
needs to include a "Type" JSON key as well.
This also makes shfmt's --to-json behave nicer on empty files;
rather than emitting `{}` lacking any information at all,
it now emits an empty file node in tthe form of `{"Type":"File"}`.
Finally, we apply some minor refactors to the code and tests.
Fixes #885.
Create a new package with docs, copy the code, and expose the API.
The following changes were made to the API:
* Name the main APIs Encode and Decode.
* Added options structs, to give us flexibility in the future.
* The "pretty" option is now an Indent string, like encoding/json.
Note that we now require "Type" keys to come first in each object.
This is not required right now, nor is it enforced by our decoder yet,
but it will be necessary to implement a performant decoder.
This is because we can only decode fields once we know the type;
if the "Type" key comes later, we must decode twice or buffer tokens.
The typed JSON encoding also changes slightly: since we want Encode and
Decode to work on syntax.Node rather than syntax.File, the root node
needs to include a "Type" JSON key as well.
This also makes shfmt's --to-json behave nicer on empty files;
rather than emitting `{}` lacking any information at all,
it now emits an empty file node in tthe form of `{"Type":"File"}`.
Finally, we apply some minor refactors to the code and tests.
Fixes #885.
Create a new package with docs, copy the code, and expose the API.
The following changes were made to the API:
* Name the main APIs Encode and Decode.
* Added options structs, to give us flexibility in the future.
* The "pretty" option is now an Indent string, like encoding/json.
Note that we now require "Type" keys to come first in each object.
This is not required right now, nor is it enforced by our decoder yet,
but it will be necessary to implement a performant decoder.
This is because we can only decode fields once we know the type;
if the "Type" key comes later, we must decode twice or buffer tokens.
The typed JSON encoding also changes slightly: since we want Encode and
Decode to work on syntax.Node rather than syntax.File, the root node
needs to include a "Type" JSON key as well.
This also makes shfmt's --to-json behave nicer on empty files;
rather than emitting `{}` lacking any information at all,
it now emits an empty file node in tthe form of `{"Type":"File"}`.
Finally, we apply some minor refactors to the code and tests.
Fixes #885.
via #760 (comment)
sh-syntax(WASM) is about 2x faster thanmvdan-shhttps://github.com/rx-ts/sh-syntax/blob/main/benchmark/benchmark.txt
The text was updated successfully, but these errors were encountered: