-
Notifications
You must be signed in to change notification settings - Fork 50
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
Support merge keys #31
Comments
I'm +1 for making this the default behavior, and also +1 on making it the only behavior (in order to avoid having to add configuration cruft) Edit: I anticipate a 0% chance that anyone using the key |
Okay @jeremyrsmith, I'm convinced—I'll PR this now and then publish it in a quick 0.6.2, and if anyone complains we can revisit in a future release. |
This approach moves the node handling to an object algebra. This allows for relatively easily adding configurable stuff that's able to change how various YAML types are handled as the need arises. One can even plug in their own algebra if they want to get nitty-gritty. It also allows adding optional error accumulation, which is something that's always felt missing. A nice thing here is by default we don't have to even check any configuration - only when a parser instance is configured do we change to `ConfiguredAlg`. Also should be binary compatible (and `yaml.parser.configure(...)` is a nice way to get a configured parser!). TODO: Add tests around error accumulation and such (coverage currently lacking)
I agree with @jeremyrsmith as well about making this the default behavior. |
SnakeYAML supports YAML's "merge key" extension, which makes the last four elements in this sequence resolve to the same thing:
This functionality isn't currently available in circe-yaml, which does resolve the references but returns JSON objects with
"<<"
keys in them.I need this functionality, and while I could hack it with cursors or something I'd rather take advantage of the fact that SnakeYAML can do it for me. This seems pretty easy—you can just subclass
org.yaml.snakeyaml.constructor.SafeConstructor
and call its protectedflattenMapping
on your mapping nodes.I'm assuming we don't want this to be the default behavior, so I think we'll want some way to set options either in the parser itself or in the
yamlToJson
method. I'm happy to take a stab at this as soon as possible but if anyone has ideas about how it should look, please let me know./cc @jeremyrsmith @jeffmay @jonas @denisrosset
The text was updated successfully, but these errors were encountered: