Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • JSON is much simpler, but to be fair it only supports a subset of what YAML does. For example it's not good for serialization, because you don't have any way to specify type names.

    Anyway, JSON being much simpler is why I wrote a JSON parser and generator for Perl 6 (with some help from Johan Viklund), see http://github.com/moritz/json/ [github.com]. As far as I can tell it implements JSON to 100%.

    • The fact that JSON only supports a subset of what YAML does is why I really like it. I know YAML is powerful and feature-rich, but JSON is much more predictable.

    • Somehow I don’t think that trying to be a serialisation format – for several languages with significant differences – and human-readable and -writeable, all at the same time, is an argument in favour of a format.

    • I had this argument with Ingy way back when he was coming up with YAML. He made it over complex (IMHO), resulting in a spec which made XML easier to implement than YAML (32 pages of spec vs nearly 200), which makes no sense since YAML was supposed to be EASIER to read and write than XML.

      It's a bit more human readable than XML, but not much, and edge cases like this are going to make it a LOT harder to debug an issue with YAML than with XML.

  • Until your post, I'd never discovered the part of the specification that isn't shown in the actual specification that describes those special strings, so I'd never known to implement them.

    2 hours later, it's now fixed. YAML::Tiny will always quote the strings listed in those secondary type specifications.

    BTW, it's not case insensitive.

    It's apparently ( $str eq uc($str) or $str eq lc($str) or $str eq ucfirst($str) )

    Still ugh though.

    • I'll be you'll break a lot of code with this. I've previously worked with a module (can't recall, but I think it was SOAP related) which was guessing my data types and silently converting things for me. No end of headaches :(

      I didn't report this to you because I assumed you had deliberately kept things simple :)

      • The YAML-Tiny language specification does not contain support for these strings, and so the PARSER half of YAML::Tiny (and thus Parse::CPAN::Meta) will not support it.

        However, in emitting YAML it's quite appropriate that I make sure to avoid causing problems for others.

        So all I'm doing is detecting that the emitted string in a hash or array is one of these magic strings, and then escaping them (when I previously wasn't).

  • For document interchange stuff I use XML and for data interchange stuff I use JSON. That works for me the majority of the time.

  • As a user (i.e. not a parser writer) I still very much prefer YAML over JSON most of the time due to it being more readable.

    But yeah, unfortunately many of the earlier Perl YAML parsers do not behave in a standard (YAML-ish) way, not to mention used to crash a lot too.

    For YAML::Syck, there's $YAML::Syck::ImplicitTyping = 1; which IIRC was turned on by default in some previous release but then Audrey reverted it back to 0 to avoid compatibility break.

    How about everybody just use YAML::XS, then?

  • The boolean documentation you link to is from the 1.1 spec. Its a bit insane to have that many special values. 1.2 took a lawn mower to it [yaml.org] and now there's just two bool values, "true" and "false".

    YAML::XS gets it right. YAML.pm is being gutted.