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.

Parse::CPAN::Meta 0.02 - YAML support in the Perl core 10 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Oh, here's one: (Score:1)

    by skazat (7326) on 2008.01.10 5:19 (#60113)
    Less a critique than a question:

    Isn't what you've done known as, "Cut and paste" Coding" -

    Wouldn't it be easier to tweak Yaml::Tiny a small bit (and give back the changes) to Do What You Need, keep it separate and just use it like you'd use any other module?

    I ask this, because the above is what I've been told to do, but much much (much) smarter people than myself. I'd probably include the OP in this group of people. One of the problems is the difficulty in having such a module live a, "Dual Life" - you're basically think that changes in one module will also be changed in another, somewhat similar module. In my experience, the modules will fall out of parity and will, basically get all wonky, in relation to each other.

    This must have been a consideration - if not the first consideration you would have thought of - why the breaking of the rule?

    I find this interesting, since it is going into core - you probably have a good reason - what is it?

    --

    !!!Dadadadadadadadadada [skazat.com]

    • The reason is pretty much stated in his post: the name YAML::Tiny is controversial. A solution that relies on that module is therefore a non-starter.

      Any time experienced people go against good practice, the reason is likely to be politics. Sometimes, technically unsound choices are the only alternative to complete standstill.

      • That's too bad. Most good new ideas are controversial.

        A benefit of using YAML::Tiny /would/ be that it would be in core. I know it's a difficult road to get modules in core anyways and that there's a push at least in Perl 6 to keep the number of core modules as small as possible, but in this project a module will have to be added anyways - why not a general purpose one?

        --

        !!!Dadadadadadadadadada [skazat.com]

        • It doesn't process YAML, for one, so the name's wrong.

          • But then neither does YAML or YAML::Syck :)
            • But then neither does YAML or YAML::Syck :)

              This is fallacious.

                * YAML.pm is an incomplete YAML implementation (true)
                * YAML::Tiny is an incomplete YAML implementation (true)
                * YAML is a good enough implementation (largely accepted as true)
                * therefore, YAML::Tiny is a good enough implementation (not largely accepted as true)
              • "Good enough" ?

                YAML::Tiny isn't a YAML parser not because it doesn't meet an arbitrary line in the sand somewhere. It isn't a YAML parser because it is incomplete and not spec-compliant.

                I can live with that.

                But to excuse the other (incomplete and non-spec compliant) parsers as well because they INTEND to meet the spec and are somehow "good enough" stinks of hypocrisy and semantic games.
        • > A benefit of using YAML::Tiny /would/ be that it would be in core.

          Exactly!

          We've seen this pattern before a number of times, so it's a fairly easy prediction to make.

          We KNOW that people have a strong preference for using modules in the core, and the controversy in this case is that IF we added it to the core we know people are going to use it in preference to a complete YAML parser, which is almost certainly going to create major headaches down the road.

          I'm quite certain that a number of people will STI
    • Development of public APIs is never just about the functionality.

      Things like module naming, method naming, the standard of documentation and so on have very real effects on how that code will be used in the real world.

      Parse::CPAN::Meta may have a YAML parser, but because it can't serialize to YAML it removes a very large use case (file storage of simple data structures) from

      > Wouldn't it be easier to tweak Yaml::Tiny a small bit (and give back the changes) to Do What You Need?

      I suspect that the one key t
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.