Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • How can a module that's unable to say what it actually does ever have a bug?

    YAML::Tiny is a misnomer and should be abandoned unless it is intending to become compliant to the YAML spec.

    Did you ever answer []
    • YAML looks simple, but is actually a bloated nightmare. Implementing the full YAML spec is tedious and difficult. Most uses of "YAML" actually use only a small subset. YAML::Tiny tries to implement this small, simple subset. I'm not sure why you find this so hard to understand.
      • by LaPerla (33) on 2007.12.11 16:53 (#59400) Journal
        > YAML::Tiny tries to implement this small, simple subset.

        If you read the manpage from the first to the last line you still have no idea what this small, simple subset actually is. Whenever you have a small, simple YAML file that fails, or a small simple perl data structure that cannot be represented in YAML via YAML::Tiny, you cannot tell if it fails because of a bug or if it fails because the author has chosen to not implement some aspect of that small simple YAML file or that small, simple perl datastructure.

        This is why I said: we have here a module that is unable to say what it does. And whenever a module does not say, exactly, what it does, we cannot tell if some behaviour is a bug or correct behaviour.

        This has nothing to do with the perception of YAML being bloated or not. I'm not opposed to having some Tinyyaml spec that is (presumably) less bloated than YAML. But somebody has to write it and thus prove that it is worth the effort. Simply saying that doing less is better is not enough, the behaviour of the lesser implementation must be specced too. Otherwise it is unusable because unpredictable.

        I hope this clarifies what I tried to say in my provocation.
        • I see your point, but I'm more willing to have the line between "bug" and "outside the spec" be negotiated between author and user. Many specs are so hairy that in practice you can only deal with them by having a general idea of their intent, then trying stuff to see what breaks. I haven't read the HTML 4 spec (746 KB of text), don't plan to, and couldn't remember it all if I did, but I can still hack together a webpage based on my rough understanding.

          The same goes (for me) for YAML::Tiny -- I'll use it