Re^2: RFC: Perl<->JSON<->YAML<->Dumper : roundtripping and possibly with unicode

Thanks for this check. I have fixed the last one. And also the last Warning (line 410), it was an empty section. But I don't understand the other warnings. (plus my podchecker for perl v5.28.2 does not show these warnings). this is the context fro one of those:

=head2 perl2yaml($perlvar, $optional_paramshashref)

Given an input C<$perlvar> (which can be a simple scalar or
a nested data structure, but not an object), it will return
the equivalent YAML string. In C<$optional_paramshashref>
one can specify whether to escape unicode with
C<'escape-unicode'=E<gt>1>. Prettify is not supported yet.
The output can fed to L<Data::Roundtrip::yaml2perl>
for getting the Perl variable back.
[download]

also, do you have an opinion about having function names with params? I don't like it when I read a manual and it mentions only sub names. So I made it very explicit what it takes in

Comment on Re^2: RFC: Perl<->JSON<->YAML<->Dumper : roundtripping and possibly with unicode Download Code

Replies are listed 'Best First'.
Re^3: RFC: Perl<->JSON<->YAML<->Dumper : roundtripping and possibly with unicode by kcott (Archbishop) on Apr 10, 2020 at 05:13 UTC
I didn't run a POD checker; however, by visual inspection, I see four instances like `C<'escape-unicode'=>1>` [download] Given there are also four, very similar warnings, that you had difficulties identifying, I'd hazard a guess that they're the source. I see in your post (to which I'm replying) you've changed one of those to `C<'escape-unicode'=E<gt>1>` [download] You may find it easier, and more readable, to use `C<< 'escape-unicode'=>1 >>` [download] That's explained in "perlpod: Formatting Codes" (you'll need to scroll down a fair way; it's past all the initial dot points in that section). I'd also recommend you add this as you first POD command paragraph: `=encoding utf8` [download] That will cover any Greek, or other non-ASCII, examples you may add. See "perlpod: Command Paragraph: =encoding" for details. "... do you have an opinion about having function names with params? I don't like it when I read a manual and it mentions only sub names." Yes, I agree that the arguments should be documented; in addition, the return value should also be described. I would typically write the example you cite something along these lines: `=head2 C<perl2yaml> my $yaml = perl2yaml($perlvar, $optional_paramshashref); The C<perl2yaml> function does ... Arguments: =over 4 =item * C<$perlvar> ... C<$perlvar> description ... =item * C<$optional_paramshashref> ... C<$optional_paramshashref> description ... =back Return value: =over 4 =item * C<$yaml> ... C<$yaml> description ... =back` [download] Although that looks like a lot of typing for every function, I'd generally set up a template for all of the formatting: that only leaves specifics to be entered. And, where you have very similar documentation, a copy, paste, and substitution can do most of the work; for instance, you could make three copies of the above then `s/yaml/json/g` in one copy and `s/yaml/dump/g` in another, and most of your work is done (the three `xxxx2perl` functions could be handled similarly). — Ken	[reply] [d/l] [select]
Re^4: RFC: Perl<->JSON<->YAML<->Dumper : roundtripping and possibly with unicode by bliako (Abbot) on Apr 10, 2020 at 14:06 UTC
noted, thanks.I will use these guidelines.	[reply]