Skip to content

Improvement: dump shorthandtags - #187

Closed
rockitbaby wants to merge 2 commits into
nodeca:masterfrom
dataliterate:improvement-dump-type-shorthandtags
Closed

rockitbaby wants to merge 2 commits into
nodeca:masterfrom
dataliterate:improvement-dump-type-shorthandtags

Conversation

@rockitbaby

Copy link
Copy Markdown
Contributor

to create more human readble output !point instead !<!point> for local tags

http://www.yaml.org/spec/1.2/spec.html#tag/shorthand/

Are there any tests for the dumper, related to formatting and styling of output?

@dervus

dervus commented Apr 29, 2015

Copy link
Copy Markdown
Collaborator

Tag shorthanding is not an option as in your implementation. It's a core feature. However it quite more complicated, and your implementation looks like a dirty hack for me because in order to properly support tag shorthanding, we also must support other types of shorthanding and %TAG directive as well.

Your implementation is probably valid, but I don't like the idea of merging this. So I'm leaving it up to @puzrin.

Are there any tests for the dumper, related to formatting and styling of output?

No.

@puzrin

puzrin commented Apr 29, 2015

Copy link
Copy Markdown
Member

Ok. Let's close it as "not complete"

@puzrin puzrin closed this Apr 29, 2015
@rockitbaby

Copy link
Copy Markdown
Contributor Author

thanks for reviewing.
you are right, the implementation only reflects one (the default) type of shorthanding, 'local tags':

The primary tag handle is a single “!” character. This allows using the most compact possible notation for a single “primary” name space. By default, the prefix associated with this handle is “!”. Thus, by default, shorthands using this handle are interpreted as local tags.
http://www.yaml.org/spec/1.2/spec.html#id2782457

Secondary Handles, Named Handles and Tag Prefixes and the %TAG directive are not reflected.

Here is a quick test based on the TEST_SCHEMA. The dumped yaml is not as readable as the original input.

'use strict';

/*eslint-disable no-console*/

var yaml = require('../../');
var TEST_SCHEMA = require('../support/schema.js').TEST_SCHEMA;

var input = 'n: !tag2 100';
var result = yaml.load(input, { schema: TEST_SCHEMA });
var dump = yaml.dump(result, { schema: TEST_SCHEMA });

console.log(dump);
// 'n': !<!tag2> '100'

Any ideas how to continue? How can I help improve the readability of dumper?
May I file an issue and provide more examples?

@puzrin

puzrin commented Apr 29, 2015

Copy link
Copy Markdown
Member

Personally, i'm not big fun of custom types use. But if someone wish to improve, and that's doable without side-effects - no problem. The only major requirement is to avoid partial hacks and provide tests.

May I file an issue and provide more examples?

Sure. It worth to disuss first all noticeable core changes. That will help to avoid rewrites and will save your time.

@dervus

dervus commented Apr 29, 2015

Copy link
Copy Markdown
Collaborator

I'd not use term "readable" here. Shorthanded tags look a bit nicer, but they still require the reader to understand YAML.

I think you misunderstood my point. I agree that support of shorthanded tags is definitely a wanted feature for the dumper, but it must be implemented properly.

@rockitbaby

Copy link
Copy Markdown
Contributor Author

support of shorthanded tags is definitely a wanted feature for the dumper, but it must be implemented properly

Sure, I think I got your point.

Sure. It worth to disuss first all noticeable core changes

I'll try summarize the needs for a more readable / nicer looking dumper output as an issue

@elorzafe

Copy link
Copy Markdown

Thanks for this library!

There is a way to dump a custom type without this !< >
?

Thanks again

@rlidwka

rlidwka commented Dec 25, 2020

Copy link
Copy Markdown
Member

This is now implemented in a0d0caa (currently in dev branch).

Same algorithm as in pyyaml, it dumps as !tag and no option to dump as !<!tag>. Please let me know if there's any need for such option.

Dumper still can't generate %TAG as of now, open a new issue if that's wanted by someone (maybe I'll implement it as well, looking into this at the moment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants