ianremmler
commented
10 years ago I considered that initially, but since shor doesn't map well directly to native types (because of the ordered, repeatable keys mainly) I skipped it for now.
The two options I can see are:
- full language: each node would be something like a []map[string]interface{}, with the map consisting of a single key/value
- subset: only allow the bits that are isomorphic to JSON, essentially, and skip the extra layer of data structure
I suspect the former would be more trouble than it's worth. The latter would get you the shor syntax without the other stuff, but it would look a lot like rjson, which already works. Let me know if I've missed any options.
Shor was mainly an experiment in designing an expressive data language with simple syntax, but I haven't used it for anything practical since making it. If you have ideas for making it more useful, please let me know.
tv42
The benefit of decoding into a struct is that 99% of my code can just access the struct, and not need to know it's using shor. Imagine migrating from json to yaml to shor; the json->yaml part is a tiny change, to switch to the current shor library would mean rewriting large chunks of the rest of the app.