On Wed, Oct 24, 2012 at 07:49:37AM +1100, Alfie John wrote: > As for integrating set() into Data::SPath. I guess I could have created a > wrapper around it as my get() would just fill in the import subroutines with > my > preferences and just copy/paste my set() in. The biggest drawback here (which > is a killer IMHO) is having a dependency. My get() subroutine is 32 lines and > set() 56 lines. Do I really want to rely on another peice of code for the sake > of 56 lines? No I don't. The less dependencies the better IMHO and I think the > majority would agree too.
Audrey Tang once said: "perl5 is just syntax. CPAN is the language." After I wrote Devel::Declare we amended it to: "perl5 is just a VM. CPAN is the language." C-level dependencies can be annoying. App::FatPacker et. al. make small, pure perl dependencies as close to free as they're going to get. You're entirely welcome to disagree, but "I think the majority would agree" comes into the unfounded assertion category - and leads people to avoid dependencies "just becase", thereby resulting in CPAN soup where you have three modules doing very similar things in a particular piece of code that all behave -slightly- differently, at which point DW(anybody)M goes out the window because the 'what' that it does changes between sections of the same codebase. Damian made a substantial effort to try and provide a 'one common way' for a lot of things with Perl Best Practices and other works; quoting him while working towards undoing some if this work seems a trifle unfair. But ... it's still your module, hence my naming suggestions went in a separate email to the 'grumpy old man' stuff above :) -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team.
